Bug Hunting Session
Bug 116640 - CRASH/Assertion when undoing columns
Summary: CRASH/Assertion when undoing columns
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
4.2 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, haveBacktrace, needUITest, regression
Depends on:
Blocks: Assert Undo-Redo Page-Layout-Columns
  Show dependency treegraph
Reported: 2018-03-26 18:24 UTC by Telesto
Modified: 2019-08-09 16:08 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["SwNode::FindTableNode()"]

bt with debug symbols (17.17 KB, text/plain)
2018-03-26 19:10 UTC, Julien Nabet
bt from SfxUndoManager::MarkTopUndoAction(): suspicious call! (12.96 KB, text/plain)
2018-03-26 19:51 UTC, Julien Nabet
bt with debug symbols (12.13 KB, text/plain)
2019-03-06 21:12 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-03-26 18:24:13 UTC
CRASH when undoing columns

Steps to Reproduce:
1. Open Writer
2. Insert -> Section -> Columns
3. Create 2 columns -> Press Insert
4. Insert some text "XXX" into the first bracket
5. Press CTRL+Z twice -> Crash

Actual Results:  

Expected Results:
No crash

Reproducible: Always

User Profile Reset: No

Additional Info:
Build ID: dd4f1b1bd31daf080dc0420524712dc244e539b5
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-03-20_23:26:38
Locale: nl-NL (nl_NL); Calc: CL

and in
Build ID: dae6ba564fcf20299b7a560aeb346efc84364d41
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-11-01_00:28:17
Locale: nl-NL (nl_NL); Calc: CL

User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Xavier Van Wijmeersch 2018-03-26 18:46:34 UTC
no repro

Build ID: 1fbe46cf08f525e78016feef83f4c38b79b337ba
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-03-24_23:04:38
Locale: nl-BE (en_US.UTF-8); Calc: group

maybe only windows???
Comment 2 Telesto 2018-03-26 18:57:26 UTC
(In reply to Xavier Van Wijmeersch from comment #1)
> maybe only windows???

Let's assume so..
Comment 3 Julien Nabet 2018-03-26 19:10:30 UTC
Created attachment 140888 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.

I attached bt with symbols + some gdb debug
Comment 4 Dieter Praas 2018-03-26 19:25:27 UTC
Reproducible with Version: (x64)

Comment 5 Xisco Faulí 2018-03-26 19:37:59 UTC
Reproduced in

Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default; 

but not in

Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)

it needs to be bisected with 5.1 repo, which is not available on linux...
Comment 6 Julien Nabet 2018-03-26 19:51:00 UTC
Created attachment 140891 [details]
bt from SfxUndoManager::MarkTopUndoAction(): suspicious call!

Thought it may help.
Comment 7 Buovjaga 2018-03-27 11:45:07 UTC
Ok, this was "a bit" convoluted to bisect. Using the original steps in bibisect repo 5.1, I got this as the bad commit:

commit	5adc8ee343e5c32d30095bc4005b7b022016b745 (patch)
tree	8148a23a2b68e26b43a308c71fac3feb43319814
parent	4ff0032528d7aebb0de5cf045a39972a2769029f (diff)
sw: fix newly created document being modified
After the document is created, an event is dispatched on the main loop
that calls SfxPickList::Notify(), which modifies document properties.

It tries to prevent setting the document to modified by calling
SfxObjectShell::EnableSetModified(false), but Writer cunningly outwits
it by simply having its own independent(?) modified flag that is set
unconditionally in DocumentStatisticsManager::DocInfoChgd().

Let's assume that if the modified flag shouldn't be modified in
SfxObjectShell, it shouldn't be modified in DocumentStatisticsManager.

Somehow in 4.4 and 4.3 the same thing was going on, but it didn't result
in a visibly enabled Save icon in the UI, but with 5.0 it does - cannot
easily bisect why that changed due to tdf#91383.

Change-Id: Id30fd831eb29910c9fb44ed3031bf8da23586bea

Adding mst to CC.

However, even in 5.0 repo I could reproduce a crash, if after step 5, I did redo (Ctrl-Y), input text again into the section, undo twice.
I continued testing and discovered this crash is already in 4.3.

So I don't know - maybe mst's commit just made this crash earlier??
Comment 8 Xisco Faulí 2018-03-27 12:29:34 UTC Comment hidden (obsolete)
Comment 9 Julien Nabet 2019-03-06 21:12:35 UTC
Created attachment 149776 [details]
bt with debug symbols

Just an update of the bt with master sources updated today.
Comment 10 Xisco Faulí 2019-04-14 18:30:06 UTC
Another crash that points to SwNode::FindTableNode()

1. Open attachment 122056 [details] from bug 85757
2. Select all
3. Copy
4. Paste 3 times
5. Undo 4 times
Comment 11 Telesto 2019-06-30 07:53:06 UTC
Repro with
Version: (x86)
Build ID: c2cb467a1e5194c56bb65706b7965fb2c9241b8f
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-06-29_00:11:35
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded
Comment 12 Xisco Faulí 2019-07-12 17:12:16 UTC
(In reply to Xisco Faulí from comment #8)
> it seems the original steps can't be reproduced with verions older than 5.0,
> but these steps can be reproduced:
> 1. Open Writer
> 2. Add a section with 2 columns
> 3. Add text to the first column
> 4. Undo 2 times
> 5. Redo 2 times
> 6. Undo to times
> I bisected it with bibisect-42max and it points me to
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=b8002169336b6b7597d32755e41fa3dc2688539e

Similar to bug 119241, see https://bugs.documentfoundation.org/show_bug.cgi?id=119241#c8, it seems that's not the problematic commit...