Description: Crash at undo Steps to Reproduce: 1. Open attachment 120527 [details] 2. Insert a 2x2 table at cursor position after file open 3. CTRL+A CTRL+X 4. Go to footnote, select the frame and press backspace 5. Go back to the footnote 6. Press and hold ctrl+V for 3 seconds 7. Press and hold ctrl+z until crash (with 10 seconds) Actual Results: Crash Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5ff701226b00963312cb2a78e77966d012b79c82 CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Not so sure this will be helpful from Linux, but I tried "selecting the table" instead of control+a (that triggers the "open file" menu for me). Then I followed the rest of steps, and no crashes. Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 16; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded
It is inconsistent and took a few tries, but I have managed to reproduce in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 960e37af28807ed1b376e26c4504ab755a81dfd5 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 24.2.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 5f390384195b7264c6e52add9e90a39790285249 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded In 7.6, I get the "BigPtrArray::Index2Block(int) const" signature: https://crashreport.libreoffice.org/stats/crash_details/2eb5b579-5a80-45d0-b1a0-4b76469bdcbc
Created attachment 191763 [details] reproducer for second set of steps More consistent steps, but with a different crash signature as a result: 1. Open this attachment 2. Copy table 3. Place cursor behind highlighted word in footnote 4. Ctrl + V, Ctrl + Z Result: https://crashreport.libreoffice.org/stats/crash_details/b07d47b6-4f8e-4d34-a30c-a4415a13ae4f In console: terminate called after throwing an instance of 'std::out_of_range' what(): basic_string_view::substr: __pos (which is 31) > this->size() (which is 0) No repro in 7.5.9 -> regression. Bibisected with linux-64-7.6 repo to first bad build commit [fcf57c8efc126fb5a1cabefd2a3e8d33c57d5860] which points to: commit ce3308a926f036b87515b8cd97d2b197063dc77a author Miklos Vajna Wed Apr 12 08:13:07 2023 +0200 committer Miklos Vajna Wed Apr 12 09:12:17 2023 +0200 tdf#61594 sw floattable: import floating tables as split flys by default Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150252 With ImportFloatingTableAsSplitFly set to true before the above commit, I get to build commit [4678abe6162fa40671a976ec7fb04e581240a852] which is: commit d477fa8ac1b0d3ee81427217bbb5950278ab16db author Miklos Vajna Fri Mar 17 14:00:17 2023 +0100 committer Miklos Vajna Fri Mar 17 14:10:34 2023 +0000 sw floattable: unconditionally map <w:tblpPr> to SwFormatFlySplit Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149044 Let's start with this crash.
Miklos, can you please have a look?
I can reproduce the problem if I copy the table from the body text (there is also one in the footnote) and if I paste it after the yellow text portion. Tables are not meant to work in footnotes in general (e.g. if you go to the footnote, then Table -> Insert Table is gray for a reason), but I appreciate the creativity to still try to get it there with a paste. :-) I'll need to understand how this generally limited scenario kind of worked before floating tables.
Created attachment 191777 [details] Reproducer without floating tables Hmm, if I remove the floating table from the bugdoc, I can still reproduce the crash, which is odd, given the above bisect result. Could you please check if this reduced document ever worked? I only tested in a debug build, there an assertion fails. Or this was a case which always resulted in an assertion failure, but now with floating tables it also crashes? Thanks.
(In reply to Miklos Vajna from comment #5) > Tables are not meant to work in footnotes in general (e.g. if you go to the > footnote, then Table -> Insert Table is gray for a reason), but I appreciate > the creativity to still try to get it there with a paste. :-) You can't underestimate the users' drive to achieve what they want! :D (In reply to Miklos Vajna from comment #6) > Hmm, if I remove the floating table from the bugdoc, I can still reproduce > the crash, which is odd, given the above bisect result. > > Could you please check if this reduced document ever worked? Thanks for the smaller reproducer! Indeed, 7.5.9 also crashes with the same comment 3 steps, with a nearly-identical trace: https://crashreport.libreoffice.org/stats/crash_details/b7b9a571-3393-4bdb-9d65-2a5be5b882ba 7.4 as well: https://crashreport.libreoffice.org/stats/crash_details/62b328c8-b305-421f-ac63-5b8f64fcac9b And 7.3: https://crashreport.libreoffice.org/stats/crash_details/c5283c40-1271-44c9-be9d-19ede57c4449 With the same std::out_of_range in console. No repro in 7.2.0.4. Bibisected with linux-64-7.3 repo to first bad build [4c1aa7dd9e977998037a56dc7a503f2c4b24385d] which points to: commit ec1c4c49301758c54394f9943252e192ad54638b author Noel Grandin Mon Nov 22 14:08:27 2021 +0200 committer Noel Grandin Tue Nov 23 14:00:08 2021 +0100 O[U]String::replaceAt overloads that take string_view Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125657 Noel, can you please have a look? This is using attachment 191777 [details] with comment 3 steps.
(In reply to Miklos Vajna from comment #5) > Tables are not meant to work in footnotes in general (e.g. if you go to the > footnote, then Table -> Insert Table is gray for a reason), but I appreciate > the creativity to still try to get it there with a paste. :-) FWIW: The situation has improved quite a lot with: https://git.libreoffice.org/core/+/e11c51eefe8c3210cef2b5850f401ba67a401d01%5E%21
I have uploaded the following patch that stops the crashing described in comment https://bugs.documentfoundation.org/show_bug.cgi?id=158740#c0 in my local build on macOS Sonoma: https://gerrit.libreoffice.org/c/core/+/162035 I don't know anything about the code surrounding this fix so I will wait for the patch to be tested and/or reviewed by someone who is familiar with that part of the Writer code. My worry is that, while LibreOffice will no longer crash, adjusting the end node might leave the current Writer document in a corrupted state.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9bfd8e69385930d8f558c767f7b29149324d1b70 tdf#158740 fix crash by checking the end node's index It will be available in 24.8.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.
Also note analysis at https://gerrit.libreoffice.org/c/core/+/162185, specifically: So the fundamental problem here is that we do not support tables in footnotes. And this bug is because we don't prevent tables from being pasted into footnotes. And when we paste a table into a footnote, we make a call to OUString::copy (or OUString::subView) with invalid arguments. But copy() has this weird bit of code that returns something useful in that case, which prevents this situation from crashing in a release build. So when I changed it to use subView(), subView() does not have the same weird error-handling code as copy(), and it started crashing.
In response to "Otherwise I will simply ignore this bug as being noise, because it is really just Telesto exploring the boundaries of writer's behaviour." https://gerrit.libreoffice.org/c/core/+/162185 --- True. The fundamental problem: Word allows tables in footnotes. Writer does not support tables in footnotes technically, but at the same the being able to import those for compatibility reasons. If imported people might tend to edit a table or add an additional table with some creativity.. It's current back and forward regarding stability. Tables in writer work pretty decent since: https://git.libreoffice.org/core/+/e11c51eefe8c3210cef2b5850f401ba67a401d01%5E%21 However "regression" are introduced rather quick because it's formally not supported. I have no idea how about the commonness of tables in footnotes. I have seen a couple of scientific papers in the bug tracker..
I believe the crash is fixed, and that thing was the regression, so this bug should be marked as fixed, too. I think we already have a bug for the missing table-in-footnote feature in general, which is nontrivial to add, but if somebody wants to do the work, it would of course make sense, given it's also a Word feature. If you would like, we could also have a follow-up non-regression bug to fix the root cause here, that the node index is negative, which should never happen. But this bug should be closed, I believe. If you agree, could you please close it? Thanks.
(In reply to Miklos Vajna from comment #13) > I believe the crash is fixed, and that thing was the regression, so this bug > should be marked as fixed, too. I can reproduce the crash with comment 3 steps and: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8b393bba91111bd4f8988457f3a78b0306462bf2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded ...which includes Patrick's steps. I can also still reproduce a crash with the comment 1 steps.
Created attachment 192040 [details] Backtrace in lldb using steps in comment 3
(In reply to Stéphane Guillou (stragu) from comment #14) > I can reproduce the crash with comment 3 steps and: > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 8b393bba91111bd4f8988457f3a78b0306462bf2 > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded > > ...which includes Patrick's steps. > > I can also still reproduce a crash with the comment 1 steps. In my local macOS build, I am seeing a new crash location at the backtrace in attachment https://bugs.documentfoundation.org/attachment.cgi?id=192040. Note: I wasn't sure what "Place cursor behind highlighted word in footnote" means, but if I place the cursor at the end of the selected word in the footnote, I can get LibreOffice to crash. It appears there is more than one path for undoing pasting a table in a footnote.
Created attachment 192043 [details] Backtrace in lldb with no undo using steps in comment 17
(In reply to Patrick Luby from comment #17) > Created attachment 192043 [details] > Backtrace in lldb with no undo using steps in comment 17 OK. I noticed something interesting: I can get my local build to crash without doing any undo steps. Below are my modified steps from comment 3: 1. Open this attachment https://bugs.documentfoundation.org/attachment.cgi?id=191777 2. Select table and copy table 3. Place cursor at the end of the highlighted word in footnote 4. Command + V 5. Press right arrow twice to move cursor after the footnote 6. Press left arrow once or twice to move cursor back to end of highlighted word in footnote 7. Crash This makes me think that some changes are getting made when pasting the table even though no table is shown in the footnote. So maybe the code isn't really ignoring the pasting of a table?
(In reply to Patrick Luby from comment #18) > 1. Open this attachment > https://bugs.documentfoundation.org/attachment.cgi?id=191777 > 2. Select table and copy table > 3. Place cursor at the end of the highlighted word in footnote > 4. Command + V > 5. Press right arrow twice to move cursor after the footnote > 6. Press left arrow once or twice to move cursor back to end of highlighted > word in footnote > 7. Crash FYI: see also bug 159023, which being pretty similar to the description above.
(In reply to Patrick Luby from comment #18) > This makes me think that some changes are getting made when pasting the > table even though no table is shown in the footnote. So maybe the code isn't > really ignoring the pasting of a table? Probably: you actually can paste a (visible) table into the footer using Special Paste RTF. In the past it would also import tables into footnote from DOC/DOCX files similar to RTF paste. Behaviour - for doc/docx (rtf?) - import changed with https://git.libreoffice.org/core/+/e11c51eefe8c3210cef2b5850f401ba67a401d01%5E! The commit added a work-around by adding a interactive frame around the table, instead of directly importing it into the footnotes
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Stéphane Guillou (stragu) from comment #14) > ...which includes Patrick's steps. (this should read "which includes Patrick's patch") (In reply to Patrick Luby from comment #18) > OK. I noticed something interesting: I can get my local build to crash > without doing any undo steps. I could not crash it with your steps, but please check with a recent build again as Michael has now fixed bug 159023.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/e1c125f6027970710eaa27bfe3d39476060878ca tdf#158740 fix crash by checking the end node's index It will be available in 24.2.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.
It's true this report has gotten messy, partly my fault. Reviewing the different steps to reproduce, with a current daily build (not debug): - comment 0: can't reproduce with original steps, but it does crash with one extra Redo step - comment 3: crash at paste (no need to undo, which Miklos confirmed in comment 5) - comment 6 and comment 16 (no floating table): crashing on paste step (no need to undo either) Telesto, can you still reproduce with comment 0 steps? If not, let's put this one to rest and open fresh reports for crashes that are still current. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bdf3b5ce49b0e4ee1b4525d344cfb037ef473059 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
(In reply to Stéphane Guillou (stragu) from comment #24) > Telesto, can you still reproduce with comment 0 steps? If not, let's put > this one to rest and open fresh reports for crashes that are still current. Yes/No. Only the first attempt; argh. The crash reporter stack was different from attached backtraces. I have to re-investigate to improve the STR Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aef28c23adc87b8e26eacb56c7dbcf652e907fb9 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded