Bug 122894 - FILEOPEN DOC: Crash: SwFrame::RemoveFromLayout()
Summary: FILEOPEN DOC: Crash: SwFrame::RemoveFromLayout()
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords: filter:doc, haveBacktrace
Depends on:
Blocks: DOC-Opening Crash
  Show dependency treegraph
 
Reported: 2019-01-23 09:55 UTC by libreoffice
Modified: 2020-11-09 14:33 UTC (History)
8 users (show)

See Also:
Crash report or crash signature: ["SwFrame::RemoveFromLayout()","SwLayoutFrame::MoveLowerFootnotes(SwContentFrame%20*,SwFootnoteBossFrame%20*,SwFootnoteBossFrame%20*,bool)"]


Attachments
imported document (2.02 MB, application/msword)
2019-01-23 09:55 UTC, libreoffice
Details
gdb backtrace (61.91 KB, text/x-log)
2019-01-23 10:23 UTC, Xisco Faulí
Details
First valgrind block accessing freed memory (16.82 KB, text/plain)
2020-04-14 13:17 UTC, Jan-Marek Glogowski
Details
Reduced document with just the affected page and surroundings (209.50 KB, application/msword)
2020-11-09 12:10 UTC, libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description libreoffice 2019-01-23 09:55:44 UTC
Created attachment 148544 [details]
imported document

This bug was filed from the crash reporting server and is br-75b5ad5b-1a7d-41af-8526-f204142efd51.
=========================================

Writer crashes when importing the attached document (downloaded from http://www.europarl.europa.eu/RegData/docs_autres_institutions/commission_europeenne/sec/2010/0791/COM_SEC(2010)0791_EN.doc).
Comment 1 Xisco Faulí 2019-01-23 10:11:43 UTC
Reproduced in

Version: 6.3.0.0.alpha0+
Build ID: 8f7c35072a6bbb33f6582c8c9a37a275c8d3cb14
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 2 Xisco Faulí 2019-01-23 10:16:46 UTC
Reproduced back to 

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 Xisco Faulí 2019-01-23 10:23:37 UTC
Created attachment 148547 [details]
gdb backtrace
Comment 4 Xisco Faulí 2019-01-23 10:24:38 UTC
Hi Caolán, this is an import crash never caught by the crash testing scripts. I thought you might be interested in this one...
Comment 5 Xisco Faulí 2019-07-29 15:18:01 UTC
Still reproducible in

Version: 6.4.0.0.alpha0+
Build ID: 0d36b32755ac662299e6a8165e9fa57311b74a2f
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 6 Xisco Faulí 2020-01-27 09:51:22 UTC
Still reproducible in

Versión: 6.3.4.2 (x86)
Id. de compilación: 60da17e045e08f1793c57c00ba83cdfce946d0aa
Subprocs. CPU: 2; SO: Windows 6.1; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded

but I get a different crash signature < http://crashreport.libreoffice.org/stats/crash_details/07a12c91-53cc-4bcd-a7b4-dd8b400a6494 >
Comment 7 Xisco Faulí 2020-03-24 11:05:19 UTC
The crash got fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=1052acae9a599c54e518c8fc17d6a994d8778757, however, it still hangs at import time...
Comment 8 Justin L 2020-04-11 14:08:36 UTC
(In reply to Xisco Faulí from comment #7)
Although that seems unlikely, I duplicate your bisect results. Reverting (and that is a bit complicated because it got changed into try2) didn't bring the crash back. Neither did reverting https://git.libreoffice.org/core/commit/81588ff2f0eb55576a5288778be2dfb5b4bc5e81
Comment 9 Xisco Faulí 2020-04-14 09:41:19 UTC
Hi Justin,
this is weird, it crashes for me again in

Version: 7.0.0.0.alpha0+
Build ID: 35fc5ef0a759884b24ed8b83cd05702a0fab64cc
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

deleting the user profile beforehand: 'rm -rf instdir/user/ && instdir/program/soffice /home/xisco/Downloads/0b12ccf28e8ee87a15ceb3a6d24aff72.doc'
Comment 10 Xisco Faulí 2020-04-14 10:04:11 UTC
(In reply to Xisco Faulí from comment #9)
> Hi Justin,
> this is weird, it crashes for me again in
> 
> Version: 7.0.0.0.alpha0+
> Build ID: 35fc5ef0a759884b24ed8b83cd05702a0fab64cc
> CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
> Locale: en-US (en_US.UTF-8); UI-Language: en-US
> Calc: threaded
> 
> deleting the user profile beforehand: 'rm -rf instdir/user/ &&
> instdir/program/soffice
> /home/xisco/Downloads/0b12ccf28e8ee87a15ceb3a6d24aff72.doc'

The crash was reintroduced after https://cgit.freedesktop.org/libreoffice/core/commit/?id=642cdf2d8341f0b202f01718ccb63ac1b976e18e, so I believe the hang started to happen after 24caeee8236576abd92086974c1dbbf15b81a4c5

@Jan-marek, I thought you might be interested in this issue...
Comment 11 Jan-Marek Glogowski 2020-04-14 13:17:43 UTC
Created attachment 159556 [details]
First valgrind block accessing freed memory
Comment 12 Jan-Marek Glogowski 2020-04-14 13:21:37 UTC
(In reply to Xisco Faulí from comment #7)
> The crash got fixed by
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=1052acae9a599c54e518c8fc17d6a994d8778757, however, it still hangs at
> import time...

So I had a look at this. If I revert the whole five patches it crashes:

Initial positioning text wrap:
 * commit dc3e213dcd81be3eee8d139ea5ad55606a44eeff
 * commit f497d1dc27b4fee3db1e2228647a00971922eb5f
 * commit 1052acae9a599c54e518c8fc17d6a994d8778757

Footnote refactoring:
 * commit 642cdf2d8341f0b202f01718ccb63ac1b976e18e
 * commit 24caeee8236576abd92086974c1dbbf15b81a4c5

If I keep that revert and just apply the two broken patches:

 * commit 1052acae9a599c54e518c8fc17d6a994d8778757
 * commit 24caeee8236576abd92086974c1dbbf15b81a4c5

it hangs, but that's the same hang as bug 131530, which I fixed with

 * commit 642cdf2d8341f0b202f01718ccb63ac1b976e18e

which was a Copy'n'Paste bug in my refactoring commit to begin with.

So while comment 7 is correct from the "user perspective", it's simply not true that the crash was ever "fixed" from the code perspective.

And the valgrind log is the same with or without the whole patchset. See the attachment 159556 [details].

Just an info for someone trying to fix this, as I just have a symbol build and the optimization makes this hard to debug further.
Comment 13 Commit Notification 2020-09-10 12:35:30 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/732d6b4209f24622972116505ad6b500e3ecc293

crashtesting: assert the condition making tdf122894-1.doc crash

It will be available in 7.1.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.
Comment 14 Xisco Faulí 2020-11-02 10:37:45 UTC
Still crashing at import time in

Version: 7.1.0.0.alpha1+
Build ID: 35f7d9a18fa7f559a1427e1b8a0f094f864f945a
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Caolán, recently you fixed an assert caused by tdf122894-1.doc, any chance you could take a look at the crash itself ?
Comment 15 Caolán McNamara 2020-11-02 11:38:58 UTC
This doc appears in the crashtesting report, my assert just clarify what thing is deleted that causes the eventual crash so its known broken at the assert point. So the document is known to me, I just haven't had a good result wrt this layout crash yet.
Comment 16 Caolán McNamara 2020-11-02 15:49:41 UTC
this seems a little similar to bug 101821 FWIW
Comment 17 libreoffice 2020-11-09 12:10:45 UTC
Created attachment 167129 [details]
Reduced document with just the affected page and surroundings
Comment 18 libreoffice 2020-11-09 12:12:47 UTC
Maybe it isn't needed to reformat the column when formatting a footnote with an object inside a column?
With `if ( pColFrameOfAnchor )` replaced by `if ( pColFrameOfAnchor && !_rAnchorTextFrame.IsInFootnote() )` in FormatAnchorFrameAndItsPrevs the document seems to display correctly (Page 116 (101)).

I've also attached a reduced document in case that helps.
Comment 19 Caolán McNamara 2020-11-09 14:33:41 UTC
That's somewhat encouraging to isolate a smaller reproducer and a workaround. Is it impossible to create working columns in a footnote anyway?