Bug 138925 - CRASH: "bad array new length" when editing table cells with faulty expressions
Summary: CRASH: "bad array new length" when editing table cells with faulty expressions
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
5.0 all versions
Hardware: All All
: low major
Assignee: Not Assigned
Keywords: notBibisectable, regression, wantBacktrace
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
Reported: 2020-12-15 07:07 UTC by deko.meister.dawg
Modified: 2023-05-23 13:49 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Writer file containing only the table to demonstrate bug (14.08 KB, application/vnd.oasis.opendocument.text)
2020-12-15 07:07 UTC, deko.meister.dawg
EXAMPLE_minimized.odt: about as small as I can get it (11.48 KB, application/vnd.oasis.opendocument.text)
2021-01-20 07:27 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description deko.meister.dawg 2020-12-15 07:07:24 UTC
Created attachment 168180 [details]
Writer file containing only the table to demonstrate bug

When editing a cell in a Writer table using table calculations (i.e. by pressing F2) that has a faulty expression in the cell (e.g. by trying to correct the faulty expression) Writer crashes after applying new formula in cell with "bad array new length" error shown in message box upon crash.

Behaviour first observed in existing table from larger document. Attached document is sanitized extract of table from that document that reliably reproduces error for me. 

Steps to reproduce
i) Move cursor to cell E5 (upper right cell with **Expression is faulty**)
ii) Edit cell formula (with F2) and enter anything
iii) Apply cell entry (by green tick)
iv) Writer crashes with warning "bad array new length"
Comment 1 Xisco Faulí 2020-12-18 18:20:20 UTC Comment hidden (obsolete)
Comment 2 Xisco Faulí 2020-12-18 18:30:00 UTC
Steps to reproduce:
1. Open document
2. Select E5:E6
3. Press F2
4. Click Apply button

-> Crash
Comment 3 Xisco Faulí 2020-12-18 18:31:38 UTC
Not reproducible in

Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 4 raal 2020-12-21 23:52:11 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2021-01-08 14:50:51 UTC
(In reply to raal from comment #4)
> It's OK in bibisect-linux-64-5.4 master, but crash in bibisect-linux-64-6.0
> oldest

it seems it's an older crash, I can also reproduce it with the oldest commit of bibisect-linux-64-5.2
Comment 6 Xisco Faulí 2021-01-08 14:53:20 UTC
Also reproducible in

Build ID: 2851ce5afd0f37764cbbc2c2a9a63c7adc844311
Locale: en_US

it crashes following the steps from comment 2 and then clicking on the document
Comment 7 Justin L 2021-01-20 07:27:52 UTC
Created attachment 169033 [details]
EXAMPLE_minimized.odt: about as small as I can get it

(In reply to raal from comment #4)
> It's OK in bibisect-linux-64-5.4 master, but crash in bibisect-linux-64-6.0
> oldest

Same problem with Linux bibisect-50max. Oldest fails, but master in bibisect-44max is fine.

The backtrace is pointing to the font cache being out of sync. My debug message prints out:
sw/source/core/txtnode/fntcache.cxx:1586: aStr is rInf.GetText[14.0][4] copy from copyStart[23]rInf.Getidx[24] CopyLen[2]rInf.GetLen[2] to CopyLen[2]

so the code is trying to copy position 23-25 from "14.0" which doesn't work very well.

Probably better leave this one to the experts, since this deals with fundamentals. And of course the fundamentals are all messed up. Why are we even getting to this section of the code? Why is rInf.GetBullet() even true for all of the text. Why wouldn't aBulletOverlay = aStr instead of doing the same copy all over again?
Comment 8 Timur 2021-05-12 08:27:26 UTC
Seems like bibisect is not possible, so I remove request.
Comment 9 Justin L 2023-05-06 00:07:39 UTC
I could never reproduce a crash - testing various bibisects back to LO 5.2.
Comment 10 Justin L 2023-05-06 00:11:06 UTC
I take that back. Just crashed it now in master.
1.) Open document.
2.) enter cell E5
3.) press F2 to edit.
4.) press the OK button 

5.) Press F2 again - crash
Comment 11 Justin L 2023-05-06 23:21:10 UTC
The problem will be somewhere in sw/source/uibase/ribbar/inputwin.cxx

There are lots of paths that crash here.

sw/source/core/txtnode/ndtxt.cxx:2374: rtl::OUString SwTextNode::InsertText(const rtl::OUString&, const SwContentIndex&, SwInsertFlags): Assertion `rIdx <= m_Text.getLength()' failed.

#4  0x00007fffbccac195 in SwTextNode::InsertText(rtl::OUString const&, SwContentIndex const&, SwInsertFlags) (this=0x555559fea200, rStr="is faulty", rIdx=
    SwContentIndex (node 57 offset 14), nMode=SwInsertFlags::NOHINTEXPAND) at sw/source/core/txtnode/ndtxt.cxx:2374
#5  0x00007fffbccac0b3 in SwTextNode::InsertText(rtl::OUString const&, SwPosition const&, SwInsertFlags)
    (this=0x555559fea200, rStr="is faulty", rIdx=SwPosition (node 57, offset 14), nMode=SwInsertFlags::NOHINTEXPAND) at sw/source/core/txtnode/ndtxt.cxx:2367
#6  0x00007fffbcd34138 in SwUndoDelete::UndoImpl(sw::UndoRedoContext&) (this=0x55555c547760, rContext=...) at sw/source/core/undo/undel.cxx:1011
#7  0x00007fffbcd3a8ce in SwUndo::UndoWithContext(SfxUndoContext&) (this=0x55555c547760, rContext=...) at sw/source/core/undo/undobj.cxx:225
#8  0x00007ffff410b5b1 in SfxListUndoAction::UndoWithContext(SfxUndoContext&) (this=0x555556925330, i_context=...) at svl/source/undo/undo.cxx:1331
#9  0x00007ffff4107239 in SfxUndoManager::ImplUndo(SfxUndoContext*) (this=0x555559f42708, i_contextOrNull=0x7fffffffbf80) at svl/source/undo/undo.cxx:715
#10 0x00007ffff4106df1 in SfxUndoManager::UndoWithContext(SfxUndoContext&) (this=0x555559f42708, i_context=...) at svl/source/undo/undo.cxx:667
#11 0x00007fffbcd12e84 in sw::UndoManager::impl_DoUndoRedo(sw::UndoManager::UndoOrRedoType, unsigned long) (this=0x555559f42700, undoOrRedo=sw::UndoManager::UndoOrRedoType::Undo, nUndoOffset=0)
    at sw/source/core/undo/docundo.cxx:696
#12 0x00007fffbcd13065 in sw::UndoManager::UndoWithOffset(unsigned long) (this=0x555559f42700, nUndoOffset=0) at sw/source/core/undo/docundo.cxx:731
#13 0x00007fffbc7ca736 in SwEditShell::Undo(unsigned short, unsigned short) (this=0x55555a3a2400, nCount=1, nOffset=0) at sw/source/core/edit/edundo.cxx:141
#14 0x00007fffbd4d2cda in SwInputWindow::CleanupUglyHackWithUndo() (this=0x55555687ae00) at sw/source/uibase/ribbar/inputwin.cxx:172
Comment 12 Justin L 2023-05-09 12:24:05 UTC
Part of the problem might be this: you get a "random" formula if you don't move the mouse over the cell before hitting F2 again. (The table has many formulas, and it returns the "most recent one" caused by whatever.

GetTableBoxFormulaAttrs is one of the "whatevers" that triggers a SwitchFormulasToExternalRepresentation which runs through each table formula. So that last one in the loop ends up being the returned value.
Comment 13 Justin L 2023-05-10 18:06:32 UTC
So, if my understanding is at all correct:
-part of the text (for some obscure reason) doesn't fit in the cell after accepting the formula, so invisible text before indicated by red arrow.
-Press F2: moveInSection moves cursor to the end of the cell (into visible area)
-delete cell text - but delete does nothing to invalidate cell frame or cursor

Bahhhh. I shouldn't try to fool myself. I don't understand any of this. And every time I turn around it crashes in a different spot.

I blame it all on failing to invalidate the text frame(s) on delete. I think the red arrow just helps get the conditions right to expose fundamental flaws.

Seeing as I don't understand this, I'm going to abandon the "helpful" patches that I developed. If anything else goes wrong, I don't want to be associated with it...

I thought that reversing the order of move in section might help - leaving the cursor at the beginning instead of at the end.

I thought that adding a StartAllAction() and EndAllAction to  SwInputWindow::ShowWin might be useful.
Comment 14 Commit Notification 2023-05-10 18:10:13 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


related tdf#138925 sw inputwin: get correct cell formula

It will be available in 7.6.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:

Affected users are encouraged to test the fix and report feedback.
Comment 15 Justin L 2023-05-23 13:49:08 UTC
This bug is not fixed. Comment 13 has a few abandoned patches as code pointers.