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
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
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.
(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
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
Set to NEW by Comment 4
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.
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 }
*** Bug 144855 has been marked as a duplicate of this bug. ***
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
(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
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
Created attachment 175851 [details] gdb full backtrace Generated with `make debugrun` and then `bt full`.
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.
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.
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.
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.