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"
Reproduced in Version: 7.2.0.0.alpha0+ Build ID: 8b3982681e98818388c09233960ad6eaacee205a CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Steps: 1. Open document 2. Place cursor in E5 3. Press a few times
Steps to reproduce: 1. Open document 2. Select E5:E6 3. Press F2 4. Click Apply button -> Crash
Not reproducible in Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
It's OK in bibisect-linux-64-5.4 master, but crash in bibisect-linux-64-6.0 oldest
(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
Also reproducible in Version: 4.5.0.0.alpha0+ Build ID: 2851ce5afd0f37764cbbc2c2a9a63c7adc844311 Locale: en_US it crashes following the steps from comment 2 and then clicking on the document
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?
Seems like bibisect is not possible, so I remove request.
I could never reproduce a crash - testing various bibisects back to LO 5.2.
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
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
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.
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... https://gerrit.libreoffice.org/c/core/+/151592 https://gerrit.libreoffice.org/c/core/+/151598 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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/24cc6f7e21844c078b8db4c505df5ca3983450b3 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This bug is not fixed. Comment 13 has a few abandoned patches as code pointers.