Description: Crash swlo!sw::WriterMultiListener::StartListening Steps to Reproduce: 1. Open the attached file 2. CTRL+A 3. CTRL+C 4. CTRL+N 5. CTRL+V 6. CTRL+Z 7. CTRL+SHIFT+V -> RTF Actual Results: Crash Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 66013201749df7d5ac5ddaf377a7b3732518a93b CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 169348 [details] Example file
Also in Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL no crash with Version: 6.4.0.0.beta1+ (x64) Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Created attachment 169349 [details] BT without symbols
Created attachment 169364 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
I tried to bisect it with bibisect-linux64-6.4 but the results are not accurate. @Telesto, please, bisect it on your side
(In reply to Xisco Faulí from comment #5) > I tried to bisect it with bibisect-linux64-6.4 but the results are not > accurate. > @Telesto, please, bisect it on your side So you could reproduce this with 6.4..while i'm looking bibisect 7.0 repro. Attempted a bibisect.. but bogus too
Yeah, it is somehow unreliable. It crashed for me even in the oldest of Linux 6.3 repo. Sometimes you have to attempt it as many as 5 times. As the steps are simple, I recommend recording a macro of them, so you can run them easily without going crazy (if you want to still investigate with older repos).
No crash with macOS Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8635c9aa8c6f1078a9e220076d5a08daf30077e8 CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Crashed on first try both with 7.4.3 and with latest of 7.5 bibisect repo on Linux Version: 7.5.0.1.0+ (X86_64) / LibreOffice Community Build ID: 09848e94d20c067499ad69edf81fa80a45d0a632 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
16969a30ad77188fe5452c42d122b205c4274948 is the first bad commit commit 16969a30ad77188fe5452c42d122b205c4274948 Author: Jenkins Build User <tdf@maggie.tdf> Date: Fri Nov 24 09:48:50 2023 +0100 source 9137bd2dd3ab66ffa783fc15a1add1e9cf541460 source 9137bd2dd3ab66ffa783fc15a1add1e9cf541460 Bisected with: linux-64-24.2 Adding Cc: to Frank Steiner
(In reply to Federico Castellani from comment #10) > 16969a30ad77188fe5452c42d122b205c4274948 is the first bad commit > commit 16969a30ad77188fe5452c42d122b205c4274948 > Author: Jenkins Build User <tdf@maggie.tdf> > Date: Fri Nov 24 09:48:50 2023 +0100 > > source 9137bd2dd3ab66ffa783fc15a1add1e9cf541460 > > source 9137bd2dd3ab66ffa783fc15a1add1e9cf541460 > > Bisected with: linux-64-24.2 > > Adding Cc: to Frank Steiner Hmm, that would be a time-traveling Frank, so let's undo the changes. Federico: as a beginner, if you see a report like this, where people are talking about how difficult it is to bisect, better to skip it.
Sorry, I don't understand it :) In which sense is patch 16969a30ad77188fe5452c42d122b205c4274948 "the first bad commit", what does that mean? I've no experience with bibisect. How could the patch be related to the crashes if those are all reported for versions that didn't contain this patch (it was added only on November 24th 2023)...?
(In reply to Frank Steiner from comment #12) > Sorry, I don't understand it :) In which sense is patch > 16969a30ad77188fe5452c42d122b205c4274948 "the first bad commit", what does > that mean? I've no experience with bibisect. > > How could the patch be related to the crashes if those are all reported for > versions that didn't contain this patch (it was added only on November 24th > 2023)...? See my comment 11, the result was a mistake by a beginner practicing bisecting.
Sorry, yes, I got that wrong :-)
Still crashing. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ed9a557e1ceb4ffa4060024b20785f04d227e06c CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
Created attachment 195701 [details] macOS crash log I can reproduce this bug on macOS in my local master build. Not sure what is happening in the code though.
Created attachment 195717 [details] Test patch that tracks and prints SwCharFormat deletions
Created attachment 195718 [details] Backtrace in lldb of deletion of SwCharFormat that causes crash
Update: the crash is due to a "use after free" of an SwCharFormat instance. In my macOS crash log in attachment #195701 [details], the crash occurs in SwClient::SwClient(SwModify*) because the SwModify* parameter is an already deleted pointer. In this particular case, the SwModify* parameter is an SwCharFormat instance stored in SwEndNoteInfo::m_pAnchorFormat. Essentially, the SwEndNoteInfo::m_pAnchorFormat pointer is getting deleted out from underneath the SwEndNoteInfo instance. Using the debug patch in attachment #195717 [details], I was able to set a break in lldb and get a backtrace of where the SwCharFormat that matches the pointer in SwEndNoteInfo::m_pAnchorFormat gets deleted. My lldb backtrace in attachment #195718 [details] shows the SwCharFormat instance that matched the pointer in SwEndNoteInfo::m_pAnchorFormat is deleted when undoing (step 6 in comment #0). I am not familiar with the inner workings of the Writer code so hopefully someone might have an idea what needs to be changed to fix this bug. Does the SwCharFormat instance need to stay alive longer? Or does the SwCharFormat destructor need to somehow notify the SwEndNotInfo instance?
In SwDoc::~SwDoc(), sw/source/core/doc/docnew.cxx:523 tries to not listen to char formats anymore in the endnote config, and only sw/source/core/doc/docnew.cxx:596 deletes the char format table, so that looks like the right order in general. Is it possible that mpEndNoteInfo->EndListeningAll() should clear the endnote info's anchor format pointer, but it does not? Or something along those lines.
(In reply to Miklos Vajna from comment #20) > In SwDoc::~SwDoc(), sw/source/core/doc/docnew.cxx:523 tries to not listen to > char formats anymore in the endnote config, and only > sw/source/core/doc/docnew.cxx:596 deletes the char format table, so that > looks like the right order in general. Is it possible that > mpEndNoteInfo->EndListeningAll() should clear the endnote info's anchor > format pointer, but it does not? Or something along those lines. AFAICT, mpEndNoteInfo->EndListeningAll() never gets called before the crash which makes sense to me as the end note should still be alive since it is held by a transferable object. I would think that SwDoc::DelCharFormat() needs to notify SwEndNoteInfo since the SwEndNoteInfo's anchor format pointer is no longer in SwDoc after the undo but it is still needed for the transferable. Then maybe the SwEndNoteInfo can make it own copy of the anchor format instance before deletion?
The more I think about this, I can't help but wonder why the transferable is holding pointers from an SwDoc instance that is being edited instead of the SwDoc for the open and unmodified window that this content was originally copied from. I understand that the content isn't rendered until pasting, but if the SwEndNoteInfo's anchor format pointer is deleted by SwDoc, doesn't that indicate that the transferable on the clipboard is now the undone content that was pasted in the second document? Related to that, shouldn't the transferable content be an immutable snapshot instead of rendered from the SwDoc state at the time of pasting? Maybe I just don't understand what is going on here, but it just seems odd to me that we use pointers from the currently edited document at render time instead of the data as it existed at the time of copying.
(In reply to Patrick Luby (volunteer) from comment #22) > Maybe I just don't understand what is going on here, but it just seems odd > to me that we use pointers from the currently edited document at render time > instead of the data as it existed at the time of copying. Just for fun, I disabled all deletion of SwDoc's SwCharFormat instances (see debug patch below) and while it stops the crash when pasting as RTF, pasting as HTML crashes. So, there is a lot more data corruption in the transferable than I originally thought. I really think the Writer developers themselves will need to take a look at this.
Created attachment 195742 [details] Backtrace in lldb where assert fails when pasting in HTML format
(In reply to Patrick Luby (volunteer) from comment #24) > Created attachment 195742 [details] > Backtrace in lldb where assert fails when pasting in HTML format I found that the crash when pasting in HTML format is probably a separate bug: an assert fails in the HTML export code and removing the assert stops that crash. So back to the original pasting in RTF format bug. While I am still unsure which SwDoc instance owns the SwEndNoteInfo's anchor format pointer, I think that might be able to avoid delving into the SwDoc and writerfilter code and fix the bug my just delaying the deletion of any anchor format pointers created by SwDoc. I'll try wrapping those pointers in rtl::Reference<SwCharFormat>. If that proves infeasible, I will try moving deletion of those pointers to the ~SwDoc().
(In reply to Patrick Luby (volunteer) from comment #25) > I'll try wrapping those pointers in rtl::Reference<SwCharFormat>. If that > proves infeasible, I will try moving deletion of those pointers to the > ~SwDoc(). I have submitted a fix for this bug in the following patch. I gave up on using shared pointers and, instead, went for the simpler approach of keeping the SwCharFormat instances alive until the SwDoc is cleared or deleted. I also replaced the assert() with a warning in the HTML export code so both pasting as RTF and HTML don't crash: https://gerrit.libreoffice.org/c/core/+/171608 Not sure if this is a good patch or not so I'll leave it to developers more familiar with the Writer code to review and approve/reject it.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7b7347bb2112d89b2ad463a464cabe0c8926e0d0 tdf#140061 keep SwCharFormat instances alive while SwDoc is alive It will be available in 25.2.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.
I have committed a fix for this bug. The fix should be in tomorrow's (10 August 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/23829f6e1cebf808f4e6ff6ed4856123ad8e8e38 tdf#140061 keep SwCharFormat instances alive while SwDoc is alive It will be available in 24.2.6. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/5b41e2ea38fba4403c830bf82a4095a265eb65d9 tdf#140061 keep SwCharFormat instances alive while SwDoc is alive It will be available in 24.8.1. 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.
Samuel Adesola committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8e7e59eddedac07ea32388168bcc71f3e521a526 tdf#140061 CPPUNIT Test for fix swlo!sw::WriterMultiListener::StartListening It will be available in 25.2.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.