Bug 135231 - Editing cut crashes Writer, seems to be when cut reduces number of pages in document
Summary: Editing cut crashes Writer, seems to be when cut reduces number of pages in d...
Status: RESOLVED DUPLICATE of bug 134298
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.6.3 release
Hardware: All All
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
Depends on:
Blocks: Writer-Header-Footer Crash
  Show dependency tree / graph
 
Reported: 2020-07-28 13:36 UTC by Bill Griffith-Jones
Modified: 2022-01-06 13:03 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Description of a database of Debtors and instructions for use. (614.70 KB, application/vnd.oasis.opendocument.text)
2020-07-28 13:36 UTC, Bill Griffith-Jones 		Details
Bibisect log (2.89 KB, text/plain)
2020-07-29 09:49 UTC, Telesto 		Details
Backtrace of the assert in the Writer layout code (7.21 KB, text/x-log)
2020-07-30 12:11 UTC, Jan-Marek Glogowski 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Griffith-Jones 2020-07-28 13:36:23 UTC 
Created attachment 163692 [details]
Description of a database of Debtors and instructions for use.

Recent work on file to add headers and footers in appendix, necessitating new Styles, and then work to add generated Contents list.  I assumed it was Contents list as I was deleting old manual Contents, but find if I go back to version before generating Contents, Writer is still crashing after a few small deletes.  Then it crashes on attempt to restore.
Have moved up from version 6.3 to 6.4 and same problem.

This file is the first I have created with Writer.
Attached the file causing the problem; it has been edited several times as ideas changed.
Comment 1 Telesto 2020-07-28 21:01:44 UTC 
Repro with
7.1

no repro with
Version: 4.3.7.2
Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba
Comment 2 Telesto 2020-07-28 21:05:33 UTC 
Found in 6.2

not in
Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 3 Telesto 2020-07-29 09:49:43 UTC 
Created attachment 163729 [details]
Bibisect log

Bisected to
author	Jan-Marek Glogowski <glogow@fbihome.de>	2018-08-17 23:10:00 +0200
committer	Jan-Marek Glogowski <glogow@fbihome.de>	2018-08-20 09:35:59 +0200
commit 401cba4c20fbc930f034168872642428d7459218 (patch)
tree 755ac9d0efcb9cb805a84f594e5cf837c018b987
parent 35a254750392dcd738481f5d6e8719cee9fb41b3 (diff)
tdf#116370 cleanup Writer idle job handing
This prevents the start of the idle job, while processing itself,
so the fixed WinSalInstance::AnyInput of commit 3bf6c97029d2
("tdf#112975 WIN correctly handle VclInputFlags::OTHER") won't
report the timer events of the re-started idle job to process.

Fixes the early abort of the background job, which resulted in
the busy loop of the reported bug and this strange printing
behaviour.

P.S. I'm not sure, why this was just broken on Windows.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=401cba4c20fbc930f034168872642428d7459218
Comment 4 Telesto 2020-07-29 09:51:48 UTC 
Adding CC: to Jan-Marek Glogowski

You uncovered a bug with your timer change.
Comment 5 Xisco Faulí 2020-07-30 11:20:23 UTC 
Steps to reproduce it:
1. Open attached document
2. Remove the header from page 1

-> Crash

Reproduced in

Version: 7.1.0.0.alpha0+
Build ID: bc44e0acef79a2c0d4f0504023be21bd78451214
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 6 Xisco Faulí 2020-07-30 11:24:22 UTC 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=401cba4c20fbc930f034168872642428d7459218

I do confirm the crash started to happen after the mentioned commit
Comment 7 Telesto 2020-07-30 11:48:05 UTC 
(In reply to Xisco Faulí from comment #6)
> > https://cgit.freedesktop.org/libreoffice/core/commit/
> > ?id=401cba4c20fbc930f034168872642428d7459218
> 
> I do confirm the crash started to happen after the mentioned commit

And I'm pretty certain it's not the 'real' cause. 
STACK_OVERFLOW_c00000fd_swlo.dll!SwAnchoredObject::SetKeepPosLocked


A simple copy/paste to new doc solves the issue
Comment 8 Telesto 2020-07-30 11:49:48 UTC 
Or saving it to docx
Comment 9 Jan-Marek Glogowski 2020-07-30 12:11:01 UTC 
Created attachment 163769 [details]
Backtrace of the assert in the Writer layout code

This hits an assert in the Writer layouting code, which was added in 

commit 1615d0eb285eeaf3da10b4ed727b776b0a28b94d
Author: Michael Stahl <mstahl@redhat.com>
Date:   Tue Mar 6 10:04:28 2018 +0100

    sw: add some sanity check to SwFrame::GetNextSctLeaf()

This commit just adds various tests and assert and AFAIK is not the cause of the bug, and I also doubt the bibisected commit is.

The reproducer to remove the header triggers it easily; thanks for that.

The idle layouter job is a tricky beast, as it has to maintain a state, where it can resume layouting after stopping from some user input.
Comment 10 Jan-Marek Glogowski 2020-07-30 12:53:00 UTC 
(In reply to Telesto from comment #8)
> Or saving it to docx

That works for me - no crash by either a bug or assert. I'm just opening the document and and selecting "save as" docx. Windows-only bug seems doubtful; or some other recent fix, but one reproducible crash is a good start.
Comment 11 Julien Nabet 2020-07-30 13:49:20 UTC 
On pc Debian x86-64 with master sources updated today + enable-dbgutil, I got the same bt as Jan-Marek.

With another build without enable-dbgutil, it seems there's an infinite loop:
Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x00007fffe6880a02 in lcl_FindContentFrame (rpContentFrame=
    @0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, 
    pFrame=0x52a6a80, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:879
879	{
(gdb) bt
#0  0x00007fffe6880a02 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x52a6a80, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:879
#1  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#2  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#3  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#4  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, --Type <RET> for more, q to quit, c to continue without paging--
pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#5  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#6  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#7  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#8  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#9  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame--Type <RET> for more, q to quit, c to continue without paging--
*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#10 0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
    at sw/source/core/layout/sectfrm.cxx:899
#11 0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&, SwFootnoteFrame*&, SwFrame*, bool&)
    (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
...
Comment 12 Jan-Marek Glogowski 2020-07-30 14:04:43 UTC 
(In reply to Julien Nabet from comment #11)
> With another build without enable-dbgutil, it seems there's an infinite loop:
> Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
> 0x00007fffe6880a02 in lcl_FindContentFrame (rpContentFrame=
>     @0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0: 0x0, 
>     pFrame=0x52a6a80, rbChkFootnote=@0x7fffffff1faf: false)
>     at sw/source/core/layout/sectfrm.cxx:879
> 879	{
> (gdb) bt
> #0  0x00007fffe6880a02 in lcl_FindContentFrame(SwContentFrame*&,
> SwFootnoteFrame*&, SwFrame*, bool&)
>     (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0:
> 0x0, pFrame=0x52a6a80, rbChkFootnote=@0x7fffffff1faf: false)
>     at sw/source/core/layout/sectfrm.cxx:879
> #1  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&,
> SwFootnoteFrame*&, SwFrame*, bool&)
>     (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0:
> 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
>     at sw/source/core/layout/sectfrm.cxx:899
> #2  0x00007fffe6880aa5 in lcl_FindContentFrame(SwContentFrame*&,
> SwFootnoteFrame*&, SwFrame*, bool&)
>     (rpContentFrame=@0x7fffffff1fb8: 0x0, rpFootnoteFrame=@0x7fffffff1fb0:
> 0x0, pFrame=0x518aea0, rbChkFootnote=@0x7fffffff1faf: false)
>     at sw/source/core/layout/sectfrm.cxx:899
...

Oh no - footnote code. It'll be a nightmare to fix. Every time I tried to refactor it into more sensible code, things broke left and right. Especially the refcount handling is a nightmare. Had my fair share of it when fixing bug 121441.
Comment 13 Telesto 2020-07-30 14:43:02 UTC 
> Oh no - footnote code. It'll be a nightmare to fix. Every time I tried to
> refactor it into more sensible code, things broke left and right. Especially
> the refcount handling is a nightmare. Had my fair share of it when fixing
> bug 121441.

Not seeing any footnotes present.. anyhow maybe another bibisect.. crashing in 5.2.5 when removing the header.. (and sometimes footer)  also in 5.3

crash report shows the same area

https://crashreport.libreoffice.org/stats/crash_details/83b7be57-3153-4192-bfcd-61be5be0e2cb

also in
Versie: 5.0.6.3 (x64)
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
Locale: nl-NL (nl_NL)

appears to be good in
4.4.7.2 (but you never know... timer differences etc.)
Comment 14 Telesto 2020-07-30 15:54:42 UTC 
Another crash report with 6.4

https://crashreport.libreoffice.org/stats/crash_details/d0af1978-9b16-4a57-bf8e-7e6cb758c238


Think the priority can be reduced. 7 crashes since the invention of the crash reporter. And 2 by me
Comment 15 BogdanB 2021-12-15 20:31:23 UTC 
Please all, retest this bug.

No crash in
Version: 7.3.0.0.beta1+ / LibreOffice Community
Build ID: ecfb83d7463bed7c89baeccc03286c1ac9956d70
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 16 Gabor Kelemen (allotropia) 2022-01-06 13:03:55 UTC 
(In reply to BogdanB from comment #15)
> Please all, retest this bug.
> 
> No crash in
> Version: 7.3.0.0.beta1+ / LibreOffice Community
> Build ID: ecfb83d7463bed7c89baeccc03286c1ac9956d70
> CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
> Locale: ro-RO (ro_RO.UTF-8); UI: en-US
> Calc: threaded

I can't reproduce the crash with "Delete first page header" step from comment #5 after:

https://git.libreoffice.org/core/+/b9ef71476fd70bc13f50ebe80390e0730d1b7afb

author	Michael Stahl <Michael.Stahl@cib.de>	Fri Nov 13 20:52:28 2020 +0100
committer	Michael Stahl <michael.stahl@cib.de>	Mon Nov 16 16:51:19 2020 +0100
tree de2c044f51addf5a7ccc32f0d3289db919d5b19e
parent 094ee3955ee81e1bc631d50cc216cbb17a777839 [diff]

tdf#134298 sw: layout: remove left-over page frame without content

*** This bug has been marked as a duplicate of bug 134298 ***