Created attachment 105445 [details] test file Steps: Open the attached test document, type "includ", and press space to halt LibreOffice (includ->include is part of the default English autocorrect list). If change tracking is disabled or Edit->Changes->Show is enabled, LibreOffice will not halt. Edit->Changes->Show shows the tracked changes of the test file: a removed paragraph with a single letter and a removed letter in the actual paragraph. Bjoern: maybe this problem is related to the changes mentioned in your letter on the development list.
Created attachment 105644 [details] Possibly related backtrace OSX 10.9.4/ 4.4 master: This doesn't crash for me after the autocomplete, but does choke on an assertion if I undo a couple of times afterwards. This does not occur if tracked changes is turned off, so I assume it may still be related. Backtrace attached. (I haven't run a bisect specifically for this, but based on an existing build I had sitting around, this still occurs at least as far back as commit ef8293485adbf6554569ca37b8c1bf8cce955842 (Fri May 30 15:11:51 2014 +0530))
On Linux, this crash occurs all the way back to the start of the 43all repository, so it's pre-bibisect On OSX, the latter symptom (crash on undo) occurs all the way back to 3.3.0 Reserving judgement about whether these two are the same issue until the code has been investigated, but in either case setting: -> Whiteboard:preBibisect
set version as per comment 2
Migrating Whiteboard tags to Keywords: (preBibisect) [NinjaEdit]
[This is an automatic message] Changing version to 3.5.7.2 in order to get rid of 'preBibisect' version as 3.5.7.2 looks to be the last version not covered by bibisect-43all.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I can't reproduce with 4.4 in Windows and Linux.
Created attachment 137425 [details] GDB trace of crash with master I repro the crash. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: af318eeb4e23694e17b09b902afb98ddf9da9b7b CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 1st 2017
Interestingly, I can reproduce it with a local build Version: 6.0.0.0.alpha1+ Build ID: fc4f2f1b0f8c286e9ae259c44fb249261a8ac47f CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group but not with a daily build Version: 6.0.0.0.alpha1+ Build ID: e90329ff3896cf33528b47830f49fcd05590bd6a CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
I cannot reproduce halt, but can reproduce crush during Undo. Crush happens during "second" undo. Firstly autocorrection undone, then during undoing insertion of "includ" crush happens. This is due to invalid node indexes (I think this is most frequent cause of crushes in undo/redo, due to their dependency of absolute node indexes...). Indexes itself made invalid during previous SwUndoInsert (autocorrection), because of redline paragraphs (one removed and one containing one removed letter) moved to special section of SwDoc for deleted redlines. This in its turn happens due to redline flags are modified during autocorrection execution. (In SwUndo redline flags set to 0n17 but diring autocorrection they set to 0n49). As a result RedlineGuard calls functions to move nodes outside of document which invalidates indexes stored in Undo. I suspect that modification of redline flags done here https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/DocumentContentOperationsManager.cxx#3900 I'll investigate this bug further.
I've removed line https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/DocumentContentOperationsManager.cxx#3901 and corresponding line https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/DocumentContentOperationsManager.cxx#4001 Bug in Undo is gone (as expected). Also I've start experiencing crush mentioned in https://bugs.documentfoundation.org/show_bug.cgi?id=83260#c8. (I think it only happens if formatting marks are OFF, but not sure). This crush also happens due to manipulation of redlining flags in DocumentContentOperationsManager::ReplaceRangeImpl and also gone with correction made. For me is absolutely unclear the reason why someone changed redlining flags in ReplaceRangeImpl method... (changed and than set back). I didn't found any code which uses these flags (only Undo stores them and when replaying crushes LO)...
This bug is tricky than seemed before... Redlining implementation is very interesting. If you change Edit->Changes->Show option (either turn show redlining ON of OFF), deleted paragraphs (if so) moved either to special section or to document itself. So this option modifies document itself (model in MVC paradigm), but not how document shown. (In my opinion, Show redlining should only change how doc is shown and not document itself). As a result indexes, stored in Undo may be invalidated and Undo will crush LO. I'll ask on dev list what to do with this issue...
I've submitted patch https://gerrit.libreoffice.org/47686
Fyodor Yemelyanenko committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aac475436271ddeabf6d9a4c3984ba77accf56ce tdf#83260 editeng sw: avoid accessing dead nodes in AutoCorrect It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c8efde4daea648204e3ba19f8edc01ef3e548bd tdf#83260 sw: call CompressRedlines() in ODF import It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
this should be fixed now on master, thanks Fyodor for the great work!
Fyodor Yemelyanenko committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aff321ae3c872ad881252979c9f10ab1a01c0ea0&h=libreoffice-6-0 tdf#83260 editeng sw: avoid accessing dead nodes in AutoCorrect It will be available in 6.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e7c67eb093d1e099225eaccdaaf29eff1a4c9325&h=libreoffice-6-0 tdf#83260 sw: call CompressRedlines() in ODF import It will be available in 6.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
addendum: the problem of the file import creating redlines that CompressRedlines() will merge can apparently happen only in the ODF import, because it creates the redlines in their special nodes-array section (i.e. as hidden); the DOC/DOCX/RTF import will insert the redlines in the body text instead (i.e. as shown), and then the AppendRedline function will already merge adjacent redlines. other formats don't have redlines.