Bug 117086 - Writer crashes when opening odt from the attached document
Summary: Writer crashes when opening odt from the attached document
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.7.2 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.2.0 target:6.1.1
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2018-04-18 12:17 UTC by kostas
Modified: 2018-08-20 10:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["SwFootnoteBossFrame::SetFootnoteDeadLine(long)"]


Attachments
fodt document (3.05 MB, application/vnd.oasis.opendocument.text-flat-xml)
2018-04-18 12:20 UTC, kostas
Details
this document crashes at import time (1.34 MB, application/vnd.oasis.opendocument.text)
2018-04-18 12:37 UTC, Xisco Faulí
Details
gdb backtrace (33.25 KB, text/plain)
2018-04-18 13:50 UTC, Xisco Faulí
Details
screenshot (360.07 KB, image/png)
2018-05-14 15:28 UTC, Xavier Van Wijmeersch
Details
valgrind log of first used of deleted SwFrame (2.40 KB, text/plain)
2018-08-14 13:23 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kostas 2018-04-18 12:17:18 UTC
Description:
If I save the attached fodt as odt, close it and re-open it, libreoffice crashes. 

Tried on three machines, Windows 7 with 6.0.3, Debian stretch with 5.2.7.2 and 6.0.0 and Ubuntu.

Steps to Reproduce:
1. open the attached
2. save as odt and close
3. re-open odt document

Actual Results:  
libreoffice crashes

Expected Results:
It should open the document


Reproducible: Always


User Profile Reset: Yes



Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Comment 1 kostas 2018-04-18 12:20:08 UTC
Created attachment 141457 [details]
fodt document
Comment 2 Dieter Praas 2018-04-18 12:35:40 UTC
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
Comment 3 Xisco Faulí 2018-04-18 12:36:47 UTC
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
Comment 4 Xisco Faulí 2018-04-18 12:37:08 UTC
Created attachment 141458 [details]
this document crashes at import time
Comment 5 Xisco Faulí 2018-04-18 13:50:21 UTC
Created attachment 141462 [details]
gdb backtrace
Comment 6 Michael Stahl (CIB) 2018-04-18 14:34:28 UTC
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.
Comment 7 Xisco Faulí 2018-04-18 14:56:00 UTC
(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?
Comment 8 Michael Stahl (CIB) 2018-04-18 15:09:25 UTC
(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
Comment 9 kostas 2018-05-13 16:07:48 UTC
Hi,

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

BR
Comment 10 Xavier Van Wijmeersch 2018-05-14 15:28:52 UTC
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
Comment 11 Caolán McNamara 2018-08-14 13:23:16 UTC
Created attachment 144169 [details]
valgrind log of first used of deleted SwFrame
Comment 12 Telesto 2018-08-14 14:11:48 UTC
Adding bug 119126 as see also
Comment 13 Caolán McNamara 2018-08-14 15:57:02 UTC
https://gerrit.libreoffice.org/#/c/58991/ makes this not crash as far as I can see
Comment 14 Commit Notification 2018-08-15 13:46:22 UTC
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.
Comment 15 Caolán McNamara 2018-08-15 13:47:55 UTC
I think I've bodged this specific case to not crash anyway (backport to 6-1 in gerrit)
Comment 16 Xisco Faulí 2018-08-15 15:47:05 UTC
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!!!
Comment 17 Commit Notification 2018-08-20 10:20:47 UTC
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.