Bug 117086

Created attachment 141457 [details]
fodt document

Crash in

Version: 5.4.6.2 (x64)
Build-ID: 4014ce260a04f1026ba855d3b8d91541c224eab8
CPU-Threads: 4; BS: Windows 6.19; UI-Render: Standard; 
Gebietsschema: en-US (de_DE); Calc: group

crashreport.libreoffice.org/stats/crash_details/455fdb31-a47a-47ed-9a22-b13e55a38bb8

and in

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 2325f9ac789cd12e5ecc9d239baf2558e1d678bb
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-05_00:37:47
Locale: en-US (de_DE); Calc: CL

Regression introduced by:

author	Michael Stahl <mstahl@redhat.com>	2016-06-09 15:52:16 +0200
committer	Michael Stahl <mstahl@redhat.com>	2016-06-09 15:59:19 +0200
commit c488214817516c13603deb1c180fef02f4c700bf (patch)
tree f139da3173a9bf65a67d7d575af5d1ddc6a9d07a
parent 6a5cb3dae1760283c2c9156de666964ea4794f0f (diff)
tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_()
The problem is that bBreakAfter is passed by reference to SwLayHelper
and stored as a reference member there, so it has to live at least as
long as pPageMaker.  (Unfortunately C++ can't statically check that.)

This then somehow caused the number of pages created after initial load
to be 812 instead of the correct 396 determined from the layout-cache in
the bugdoc, and that then caused Drawing objects to move backward during
the following re-pagination, and then SwDrawContact::Changed_() calls
SetFlyFrmAttr() and that sets the document to modified, which triggers the
AutoSave that was reported in the bug.

Bisected with: bibisect-linux-64-5.3

Adding Cc: to Michael Stahl

Created attachment 141458 [details]
this document crashes at import time

Created attachment 141462 [details]
gdb backtrace

the commit in comment #3 is very likely a red herring, please check if it crashes with the parent of commit b4b7703e4335460cf48bfd6440f116359994c8ff where that flag was in the same place.

if not, it would be useful to have a bisect between those two with  b4b7703e4335460cf48bfd6440f116359994c8ff reverted at each step.

(In reply to Michael Stahl from comment #6)
> the commit in comment #3 is very likely a red herring, please check if it
> crashes with the parent of commit b4b7703e4335460cf48bfd6440f116359994c8ff
> where that flag was in the same place.

if you mean whether it crashes at https://cgit.freedesktop.org/libreoffice/core/commit/?id=90d82f73b89d8a0b0b13d224dbd1a741a10a7fd9

No, it doesn't crash

Version: 5.1.0.0.alpha1+
Build ID: 90d82f73b89d8a0b0b13d224dbd1a741a10a7fd9
Locale: en-US (en_ES.UTF-8)

> 
> if not, it would be useful to have a bisect between those two with 
> b4b7703e4335460cf48bfd6440f116359994c8ff reverted at each step.

Which two do you mean?

(In reply to Xisco Faulí from comment #7)
> (In reply to Michael Stahl from comment #6)
> > the commit in comment #3 is very likely a red herring, please check if it
> > crashes with the parent of commit b4b7703e4335460cf48bfd6440f116359994c8ff
> > where that flag was in the same place.
> 
> if you mean whether it crashes at
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=90d82f73b89d8a0b0b13d224dbd1a741a10a7fd9
> 
> No, it doesn't crash

i'm guessing the crash was introduced between the 2 commits but masked by the bug in reading of the layout-cache.

> Version: 5.1.0.0.alpha1+
> Build ID: 90d82f73b89d8a0b0b13d224dbd1a741a10a7fd9
> Locale: en-US (en_ES.UTF-8)
> 
> > 
> > if not, it would be useful to have a bisect between those two with 
> > b4b7703e4335460cf48bfd6440f116359994c8ff reverted at each step.
> 
> Which two do you mean?

between b4b7703e4335460cf48bfd6440f116359994c8ff and c488214817516c13603deb1c180fef02f4c700bf

Hi,

Is anyone looking into this? Or can someone, please, tell me how to fix the document so that it will usable again?

BR

Created attachment 142095 [details]
screenshot

After the crash i have this error message with home build lo 20180513, see attachment

Version: 6.1.0.0.alpha1+
Build ID: 48cf194a1bdd7625c58edd201a7d5191fcd0f934
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Created attachment 144169 [details]
valgrind log of first used of deleted SwFrame

Adding bug 119126 as see also

https://gerrit.libreoffice.org/#/c/58991/ makes this not crash as far as I can see

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4989ae8ca0d8b37e98caa5b68c164c79d27d574

tdf#117086 crash on deleted SwFootnoteBossFrame

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I think I've bodged this specific case to not crash anyway (backport to 6-1 in gerrit)

Verified in

Version: 6.2.0.0.alpha0+
Build ID: 1af7f19224f18e5025352339648db659575eae33
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

@Caolán, Thanks for fixing this!!!

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d1b9cbe749fc3329bda1e8ddaee6d8a6f783ad82&h=libreoffice-6-1

tdf#117086 crash on deleted SwFootnoteBossFrame

It will be available in 6.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.