Bug 158740 - Crash at undo after pasting table in footnote
Summary: Crash at undo after pasting table in footnote
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.0.0.alpha1+
Hardware: All All
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: target:24.2.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Crash-BigPtrArray
  Show dependency treegraph
 
Reported: 2023-12-17 02:15 UTC by Telesto
Modified: 2024-04-17 00:05 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["BigPtrArray::Index2Block(int) const","libc.so.6"]


Attachments
reproducer for second set of steps (9.75 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-01-04 16:26 UTC, Stéphane Guillou (stragu)
Details
Reproducer without floating tables (9.36 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-01-05 15:39 UTC, Miklos Vajna
Details
Backtrace in lldb using steps in comment 3 (7.84 KB, text/plain)
2024-01-18 17:53 UTC, Patrick Luby (volunteer)
Details
Backtrace in lldb with no undo using steps in comment 17 (6.51 KB, text/plain)
2024-01-18 18:28 UTC, Patrick Luby (volunteer)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2023-12-17 02:15:19 UTC
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
Comment 1 Raúl Osuna 2023-12-29 16:21:19 UTC
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
Comment 2 Stéphane Guillou (stragu) 2024-01-04 00:39:10 UTC
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
Comment 3 Stéphane Guillou (stragu) 2024-01-04 16:26:31 UTC
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.
Comment 4 Stéphane Guillou (stragu) 2024-01-04 16:28:31 UTC
Miklos, can you please have a look?
Comment 5 Miklos Vajna 2024-01-05 15:10:29 UTC
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.
Comment 6 Miklos Vajna 2024-01-05 15:39:55 UTC
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.
Comment 7 Stéphane Guillou (stragu) 2024-01-05 20:58:59 UTC
(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.
Comment 8 Telesto 2024-01-05 23:03:04 UTC
(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
Comment 9 Patrick Luby (volunteer) 2024-01-14 00:45:11 UTC
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.
Comment 10 Commit Notification 2024-01-17 08:58:27 UTC
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.
Comment 11 Noel Grandin 2024-01-17 09:00:31 UTC
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.
Comment 12 Telesto 2024-01-17 09:01:59 UTC
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..
Comment 13 Miklos Vajna 2024-01-18 07:55:58 UTC
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.
Comment 14 Stéphane Guillou (stragu) 2024-01-18 16:02:02 UTC
(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.
Comment 15 Patrick Luby (volunteer) 2024-01-18 17:53:29 UTC
Created attachment 192040 [details]
Backtrace in lldb using steps in comment 3
Comment 16 Patrick Luby (volunteer) 2024-01-18 18:00:35 UTC
(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.
Comment 17 Patrick Luby (volunteer) 2024-01-18 18:28:37 UTC
Created attachment 192043 [details]
Backtrace in lldb with no undo using steps in comment 17
Comment 18 Patrick Luby (volunteer) 2024-01-18 18:47:10 UTC
(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?
Comment 19 Telesto 2024-01-18 19:14:56 UTC
(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.
Comment 20 Telesto 2024-01-18 20:08:26 UTC
(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
Comment 21 QA Administrators 2024-01-19 03:14:22 UTC Comment hidden (obsolete)
Comment 22 Stéphane Guillou (stragu) 2024-01-25 06:29:52 UTC
(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.
Comment 23 Commit Notification 2024-02-08 12:31:22 UTC
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.
Comment 24 Stéphane Guillou (stragu) 2024-04-17 00:05:53 UTC
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