Bug 144650 - LO crashes after opening of read-only file (attempt to increment a singular iterator)
Summary: LO crashes after opening of read-only file (attempt to increment a singular i...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.2.0.1 rc
Hardware: All All
: highest critical
Assignee: Noel Grandin
URL:
Whiteboard: target:7.3.0 target:7.2.3
Keywords: bibisected, bisected, regression
: 144855 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-09-21 21:33 UTC by Roman Kuznetsov
Modified: 2021-10-22 07:21 UTC (History)
9 users (show)

See Also:
Crash report or crash signature: ["`anonymous namespace'::CheckReadOnlyTask::doWork"]
Regression By:


Attachments
gdb full backtrace (17.33 KB, text/x-log)
2021-10-20 14:20 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2021-09-21 21:33:44 UTC
Description:
LO crashes after opening of read-only file

Steps to Reproduce:
1. Create an empty ODS file and save it. Close it in LO
2. Open the file's Properties
3. Change its attributes to read-only => press OK button
4. Open it in LibreOffice
5. You'll see a some warning window with three buttons => Press Notify
6. In opened file press Edit document on the bar in top part of LO window
7. Open another software like FireFox
8. Wait around 1 minute => LO crashes

https://crashreport.libreoffice.org/stats/crash_details/5ebca11b-fad1-4f18-8de5-4ea49d9e1554

On Windows 7 I see a zombie soffice.bin process after crashing

Actual Results:
LO crashes

Expected Results:
LO works fine


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.0.4 (x64) / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL

but not in 7.1.5 => regression

I bisected in using win64-7.2 bisect repo and got a sha
 95eb088802562b75f8b299908160145c7e88d763

https://gerrit.libreoffice.org/c/core/+/111654

https://git.libreoffice.org/core/commit/95eb088802562b75f8b299908160145c7e88d763

Added CC: to Matt K and Mike Kaganski
Comment 1 Buovjaga 2021-09-22 07:13:48 UTC
I can't reproduce it

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 47a8a65022e3fd7624c95d0341b4809aad11fddb
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded Jumbo

Arch Linux 64-bit
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 504d2209e47ffeb223b2bcde9fc24e828cc5cd6f
CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 21 September 2021
Comment 2 Mike Kaganski 2021-09-22 07:20:16 UTC
For me, opening this link in FF on Windows:

https://bugs.documentfoundation.org/attachment.cgi?id=96007

and choosing "open with"->LO master results in immediate crash of LO master on load after "notify", without "Edit document", and without any file attribute modifications.

But trying to repro OP steps doesn't crash on my system, too.
Comment 3 Roman Kuznetsov 2021-09-27 16:42:58 UTC
(In reply to Mike Kaganski from comment #2)
> For me, opening this link in FF on Windows:
> 
> https://bugs.documentfoundation.org/attachment.cgi?id=96007
> 
> and choosing "open with"->LO master results in immediate crash of LO master
> on load after "notify", without "Edit document", and without any file
> attribute modifications.

Because FF saves the file into temp directory already with read-only attribute
Comment 4 Bigor 2021-09-27 19:33:28 UTC
Version: 7.2.1.2 / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU
7.2.1-2
Calc: threaded

Confirming the problem
When opening * .ods, * .xlsx files (example https://forumooo.ru/index.php?action=dlattach;topic=8834.0;attach=15497) and selecting Notify 
LO crashes in 1-2 minutes
Comment 5 Roman Kuznetsov 2021-09-27 19:44:56 UTC
Set to NEW by Comment 4
Comment 6 Kevin Suo 2021-09-28 10:11:49 UTC
You actually do not need to enable "Edit Document" before it crashes. You just need to open an read-only file, and wait for some time while you are doing some normal operation on your computer.
Comment 7 Kevin Suo 2021-09-28 10:27:34 UTC
I tried to get a backtrace (on Linux), but failed. Instead, I get the following output in terminal: 

/usr/include/c++/11/debug/safe_iterator.h:330:
In function:
    __gnu_debug::_Safe_iterator<_Iterator, _Sequence, _Category>& 
    __gnu_debug::_Safe_iterator<_Iterator, _Sequence, 
    _Category>::operator++() [with _Iterator = 
    std::__detail::_Node_iterator<std::pair<SfxMedium* const, 
    std::shared_ptr<{anonymous}::ReadOnlyMediumEntry> >, false, false>; 
    _Sequence = std::__debug::unordered_map<SfxMedium*, 
    std::shared_ptr<{anonymous}::ReadOnlyMediumEntry> >; _Category = 
    std::forward_iterator_tag]

Error: attempt to increment a singular iterator.

Objects involved in the operation:
    iterator "this" @ 0x0x7f3467b48190 {
      type = std::__detail::_Node_iterator<std::pair<SfxMedium* const, std::shared_ptr<(anonymous namespace)::ReadOnlyMediumEntry> >, false, false> (mutable iterator);
      state = singular;
      references sequence with type 'std::__debug::unordered_map<SfxMedium*, std::shared_ptr<(anonymous namespace)::ReadOnlyMediumEntry>, std::hash<SfxMedium*>, std::equal_to<SfxMedium*>, std::allocator<std::pair<SfxMedium* const, std::shared_ptr<(anonymous namespace)::ReadOnlyMediumEntry> > > >' @ 0x0x7f3484bc56a0
    }
Comment 8 Mike Kaganski 2021-10-01 16:12:32 UTC
*** Bug 144855 has been marked as a duplicate of this bug. ***
Comment 9 Roman Kuznetsov 2021-10-16 08:28:43 UTC
If an author or someone else can't fix it I suggest revert the problem patch. Today current behavior just makes LO testing harder (for me at least) and I don't think users who uses LO 7.2 are happy when LO crashes with just directly opened from the Internet files
Comment 10 Xisco Faulí 2021-10-20 09:02:09 UTC
(In reply to Roman Kuznetsov from comment #9)
> If an author or someone else can't fix it I suggest revert the problem
> patch. Today current behavior just makes LO testing harder (for me at least)
> and I don't think users who uses LO 7.2 are happy when LO crashes with just
> directly opened from the Internet files

not so trivial at this point, if possible I'd rather see a fix than a revert
Comment 11 Xisco Faulí 2021-10-20 10:24:28 UTC
Hi Michael Stahl,
Since you fixed a regression introduced by https://cgit.freedesktop.org/libreoffice/core/commit/?id=95eb088802562b75f8b299908160145c7e88d763 today ( https://cgit.freedesktop.org/libreoffice/core/commit/?id=a86b0e83177f15320c4fe2906a0a02486ba60d49 ) I thought you might also be interested in this issue
Comment 12 Kevin Suo 2021-10-20 14:20:24 UTC
Created attachment 175851 [details]
gdb full backtrace

Generated with `make debugrun` and then `bt full`.
Comment 13 Kevin Suo 2021-10-20 14:44:17 UTC
Simple Steps to Reproduce:

1. Use any ODS or XLSX file as test doc (even blank), chmod it to read-only mode.
2. Open the file with libreoffice, wait for around 60 second.

-> Crash.
Comment 14 Kevin Suo 2021-10-21 09:34:49 UTC
There are actually two crashes: one is when the file is still read-only at the 60-second time point; another is at the time when the file is back to read-write mode (in case there is no crash at its previous stage).

Noel Grandin has submitted a patch on gerrit and I tested that the patch works perfect both on master and 7.2 branch:
https://gerrit.libreoffice.org/c/core/+/123948

With this patch, when the file is back to read-write mode it is not possible to receive the "enable editing" notification, which is what originally designed by https://git.libreoffice.org/core/commit/95eb088802562b75f8b299908160145c7e88d763.
Comment 15 Commit Notification 2021-10-21 11:12:32 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6772ed1dcd0a3f89f65375e10cba06544c46226a

tdf#144650 crash after opening of read-only file

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2021-10-22 06:31:56 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/a692b0f1229fa92e1ce773b1d3aa0522b2617f3d

tdf#144650 crash after opening of read-only file

It will be available in 7.2.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.