Bug 119126 - Crash in: SwFrame::PrepareMake(OutputDevice *)
Summary: Crash in: SwFrame::PrepareMake(OutputDevice *)
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
5.2 all versions
Hardware: All All
: highest critical
Assignee: Not Assigned
Whiteboard: target:6.1.5
Keywords: bibisected, bisected, haveBacktrace, regression
: 119108 119125 (view as bug list)
Depends on:
Blocks: Writer-Table-Layouting
  Show dependency treegraph
Reported: 2018-08-06 15:18 UTC by Telesto
Modified: 2022-01-06 13:09 UTC (History)
3 users (show)

See Also:
Crash report or crash signature: ["SwFrame::FindFootnoteBossFrame(bool)", "SwFrame::PrepareMake(OutputDevice *)"]

gdb bt (32.32 KB, text/plain)
2018-08-09 20:09 UTC, Julien Nabet
sample file in sigle page view (15.51 KB, application/vnd.oasis.opendocument.text)
2018-11-29 12:17 UTC, Xisco Faulí
gdb backtrace (36.58 KB, text/plain)
2018-11-29 12:19 UTC, Xisco Faulí

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-08-06 15:18:09 UTC
This bug was filed from the crash reporting server and is br-3c18620f-0706-4bc3-8436-1604899e8a85.

Pretty similar to bug 119125
1. Open attachment 143995 [details]
2. Press CTRL+A in Cell A1 
4. Paste somewhere at the yellow marking on the second page (will move up to the first when clicking)
6. Page scrolls down
7. Scroll up again to the initial pasting point (using the drag slider at the right or the scroll wheel or a combination).. it will crash in 1/4 or so
8. It certainly crashes when pasting the same content at the same place again (again with a different trace)

Different crash with similar steps: http://crashreport.libreoffice.org/stats/crash_details/74a1161a-320c-4e59-bef7-661282713c13
Comment 1 Xisco Faulí 2018-08-06 20:05:31 UTC
Regression introduced by:


author	Miklos Vajna <vmiklos@collabora.co.uk>	2016-03-23 16:44:43 +0100
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2016-03-23 16:36:48 +0000
commit b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 (patch)
tree 861f662a721df5bd3f6a2569db0d3ae49864972f
parent 11231f9179db9821effc884e8adade48fdf89938 (diff)
tdf#88453 sw layout: fix split of nested tables with large amount of rows

Bisected with: bibisect-linux-64-5.2

Adding Cc: to Miklos Vajna
Comment 2 Xisco Faulí 2018-08-06 20:06:03 UTC
Adding Cc: to Miklos Vajna
Comment 3 Xisco Faulí 2018-08-06 21:27:47 UTC
*** Bug 119125 has been marked as a duplicate of this bug. ***
Comment 4 Julien Nabet 2018-08-09 20:09:24 UTC
Created attachment 144071 [details]
gdb bt

On pc Debian x86-64 with master sources updated today, I got a crash before pasting.
Comment 5 Telesto 2018-08-10 14:23:39 UTC
*** Bug 119108 has been marked as a duplicate of this bug. ***
Comment 6 Miklos Vajna 2018-08-15 13:55:09 UTC
Is this reproducible now that bug 117086 is fixed?
Comment 7 Xisco Faulí 2018-08-15 15:49:55 UTC
(In reply to Miklos Vajna from comment #6)
> Is this reproducible now that bug 117086 is fixed?

Yep, still reproducible in

Build ID: 1af7f19224f18e5025352339648db659575eae33
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Comment 8 Telesto 2018-08-15 19:29:01 UTC
Bug 116293 might be related to. Compare BT comment 4 & bug 116293 comment 12
Comment 9 Miklos Vajna 2018-08-16 07:27:48 UTC
(In reply to Xisco Faulí from comment #7)
> Yep, still reproducible

OK, thanks. One can dream... :-)
Comment 10 Xisco Faulí 2018-11-29 12:17:25 UTC Comment hidden (obsolete)
Comment 11 Miklos Vajna 2018-11-29 12:19:18 UTC
Is there any step between 2. and 3.? Like "select all"? If you just put the cursor somewhere and hit copy, I don't think anything happens.
Comment 12 Xisco Faulí 2018-11-29 12:19:48 UTC
Created attachment 147139 [details]
gdb backtrace
Comment 13 Xisco Faulí 2018-11-29 12:21:18 UTC
1. Open attached file
2. Put cursor in cell A1
3. Select All
4. Copy
5. Scroll to page 2, put the cursor after the yellow mark, and paste
Comment 14 Xisco Faulí 2018-11-29 12:46:28 UTC
I assume the correct crash signature for this crash is http://crashreport.libreoffice.org/stats/crash_details/2fe96f40-a9ea-4a78-86eb-63a8428d520e
Comment 15 Xisco Faulí 2018-11-29 12:47:52 UTC
Increasing severity taking into account the number of crashes in the crashreport service
Comment 16 Xisco Faulí 2018-11-29 12:55:00 UTC
Just to be sure, I reverted b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 locally and the crash from comment 13 is not reproducible...
Comment 17 Miklos Vajna 2019-01-15 13:36:32 UTC
So I took a stab at this, and I wonder perhaps this is already fixed by 0005b330eaed0b5559042d2597fb45e0c9125d7e (forcepoint#76 avoid deleting footnote that would delete undeletable page, 2018-12-05)?

Here is what I tried:

- the bug document and repro steps were hard for me from this bug, I could not work out a way to reliably trigger the crash
- I went over to bug 119125, which is a duplicate of this bug, and there the following repro steps always happened to me:

1) open the bugdoc
2) go to A1
3) Ctlr-A
4) Ctrl-C
5) Go to after "xx" in the yellow "xxxx" (middle of it)
6) paste
7) Go to after "x" in the first yellow "xx" (middle of it)
8) paste -> wait -> should crash

I noticed that (guessing based on the date of the last comment of this bug) bibisect-linux-64-6.3 commit 483a135e crashes reliably this way, but not bibisect-linux-64-6.3 master. So I reverse bisected what commit fixed this scenario and found the above commit.

All in all: should this be closed, knowing that the above commit is already in master and libreoffice-6-2? Or all what's left is to cherry-pick that further to libreoffice-6-1?
Comment 18 Telesto 2019-01-15 14:23:03 UTC
I'm still able the produce crashes with the document, but without clear reliable  steps.. 
Build ID: 61778fd20395794d2de3b52d60dcc65083aecd93
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL

also the backtrace seems different
Comment 19 Xisco Faulí 2019-01-15 14:28:11 UTC
Indeed, it's fixed in

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


Build ID: cec7ae9f3c69ecc83462f28fc4987e37dc1b420e
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

if steps from comment 13 are followed.

@Telesto, Please report a follow-up bug if you find new reliable steps to reproduce a crash!
Comment 20 Xisco Faulí 2019-01-15 16:41:10 UTC
(In reply to Miklos Vajna from comment #17)
> So I took a stab at this, and I wonder perhaps this is already fixed by
> 0005b330eaed0b5559042d2597fb45e0c9125d7e (forcepoint#76 avoid deleting
> footnote that would delete undeletable page, 2018-12-05)?

I do confirm my steps from comment 13 are fixed by 0005b330eaed0b5559042d2597fb45e0c9125d7e
Comment 21 Commit Notification 2019-01-15 16:47:48 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":


tdf#119126 forcepoint#76 avoid deleting footnote that would delete ...

It will be available in 6.1.5.

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:

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