Bug 101821 - Scrolling and then clicking into document with endnotes crashes Writer
Summary: Scrolling and then clicking into document with endnotes crashes Writer
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high critical
Assignee: Michael Stahl
URL:
Whiteboard: target:6.0.0 target:5.3.5 target:5.4.0.2
Keywords: haveBacktrace
Depends on:
Blocks:
 
Reported: 2016-08-31 15:49 UTC by 510jrb2301
Modified: 2017-09-14 17:19 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["SwFrame::FindNext_()","SwTextFrameBreak::SwTextFrameBreak(SwTextFrame *,long)"]


Attachments
This is the .odt file which is causing the problem (580.47 KB, application/vnd.oasis.opendocument.text)
2016-09-06 00:04 UTC, 510jrb2301
Details
Recovered version of the .odt file (done with v5.2.2.1) (544.68 KB, application/vnd.oasis.opendocument.text)
2016-09-20 16:14 UTC, Aron Budea
Details
Comments on the recovered file. (580.47 KB, application/vnd.oasis.opendocument.text)
2016-09-22 15:26 UTC, 510jrb2301
Details
gdb backtrace (138.04 KB, text/plain)
2017-03-03 10:25 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 510jrb2301 2016-08-31 15:49:29 UTC

    
Comment 1 510jrb2301 2016-08-31 15:54:42 UTC
When working on a large file sectioned to indices last, the file opens, then changes a page, then another, then another, then crashes back to Ubuntu, right out of Writer.   Reopening Writer, the file looks to be recovered.  Upon recovery, file open and repeats the page changes and crashes out of Writer.  What is going on?
Comment 2 Aron Budea 2016-08-31 16:07:50 UTC
LibreOffice 4.2.6.2 is really old, and not supported anymore, please try with a recent version (5.1.5 or 5.2.0).
Comment 3 510jrb2301 2016-09-02 14:10:33 UTC
Though updated to ver 5.2 Writer, still crashes with a report: "due to an unexpected error", LibreOffice has crashed.  The reaction to ver 5.2 differs somewhat from earlier crashes in that Writer moves more pages around automatically before crashes.  It also seems to recycle the same pages. 

This Writer file contains close to 600 KB with endnotes and indices.  The text and endnotes have been enclosed in a single section.  The indices have been placed after the section.  On earlier loading, a portion of the endnotes were converted to footnotes and the pagination was altered.  Somehow the footnotes were afterward converted to endnotes again with subsequent realteration of the pagination.  At present the file loads, then gyrates or cycles through several pages and crashes.

Your help in recovering the file will be mightily appreciated. 

JRB
Comment 4 Aron Budea 2016-09-02 23:01:23 UTC
Is there a chance you could attach the file here? (if it doesn't contain any personal/sensitive information)

What's the history of this file? Was it working fine until now, and this behavior started after some recent changes?

If you could attach a backtrace, that could also offer some hints, the way to get it is described in [1].
The most helpful would certainly be the document itself. Unfortunately there's a chance it might be corrupt, but nothing certain can be said at this point.

But before anything else, please go through the steps in [2], in particular steps 2 and 3 (4 isn't applicable). Even if the chance they help is slim, it's the easiest to do.

[1] https://wiki.documentfoundation.org/QA/BugReport/Debug_Information
[2] https://wiki.documentfoundation.org/QA/FirstSteps
Comment 5 510jrb2301 2016-09-06 00:04:40 UTC
Created attachment 127161 [details]
This is the .odt file which is causing the problem

You have been most helpful.  Setting a new user profile did not clear the problem.  The rendering was set to default.

I'm not sure how to upload the file to you.  I've used the browse button above.  I also set it as an attachment to the email, but that was returned as failed.
Comment 6 Aron Budea 2016-09-06 01:18:02 UTC
Thanks for your reply, attaching the file to the bug report is perfectly fine.

Crash reproduced in v5.2.1.2, v5.1.5.2, v4.4.0.3, v4.0.0.3, v3.3.0 / Windows 7.
Sometimes I had to scroll/click around a few times for it to crash.

Raising priority to critical as it's a crash.
Crash report: http://crashreport.libreoffice.org/stats/crash_details/93e1548e-e0d4-4291-b433-c0dd82ae3c19
Comment 7 510jrb2301 2016-09-19 14:00:49 UTC
Hi Aron.  Will I be able to recover my file eventually without having it crash on me?  Is there a way of loading the file, freeze it before it begins gyrating so I can strip out a workable section?  Or must I wait for the bug in Writer to be found and update Writer?

Again thanks for your help.
Comment 8 Aron Budea 2016-09-19 19:53:23 UTC
Hi Joseph. You could try Ctrl-A, Ctrl-C, then Ctrl-V into a new document, and see how different the resulting document is. Please give update on the situation afterwards so we can see if further advice is needed.
Comment 9 510jrb2301 2016-09-20 14:02:06 UTC
AMDG

Aron.  Here are the results: 
Ctrl A            Select all does not operate as intended.  Gyrating does not stop
Ctrl C            does not exit file; gyrating does not stop
Ctrl V            When dropped into a new file, the only text captured is the header on the page which is first displayed. 

Upon loading the file may be immediately closed, but the reloaded file still gyrates.  I think the file may be closed at any time before crashing. 

Also all other open files will crash along with the gyrating file.  Reopening Writer will bring all these files into recovery along with the gyrating file. 

Hope this helps.

JRB
Comment 10 Aron Budea 2016-09-20 16:14:43 UTC
Created attachment 127477 [details]
Recovered version of the .odt file (done with v5.2.2.1)

For me there's no immediate hang, so if I press Ctrl-A without scrolling, the whole document can be selected without Writer hanging.

I'm attaching the file recovered with this method. There are some differences, but I hope it's helpful.
Comment 11 510jrb2301 2016-09-22 15:26:41 UTC
Created attachment 127550 [details]
Comments on the recovered file.

Thank you, Aron. Your comment was helpful and appreciated.

Here are some comments on the recovered file. 
1. The section has been ignored.  The recovered file contains only the original section.  The indices,etc. outside of the section were not recovered.
2. The first few pages of the recovered file have the page style changed to the endnote page style.  This includes a header change.
3. The page enumeration which had been put into a frame is missing, both frame and page number
4.Cross references have been reduced to a single cross reference.
5.Rendering for some pages has been changed, that is, paragraphs have spilled over to the following page, or conversely, shortened to bring a paragraph or part of a paragraph into a preceding page.
6. Endnotes have remained endnotes, but the notation has gone from arabic to roman.

I used your insight to command Ctrl End which interrupted the gyrating, and found the indices, which I copied to a separate file without difficulty. 

Feeling more confident, I commanded Ctrl Home, which jumped me to the beginning of the file.  The formatting was just as with the initial file.  The section appeared; the page style was correct; frames for the page numbers appeared.  So I attempted to save the first few pages, but the system crashed when I scrolled to the page with the first footnote.  I suspect we are interrupting the gyrating, but it still continues like a background activity until the crash.

Hope this helps.

JRB
Comment 12 Aron Budea 2016-10-16 23:17:02 UTC
In 5.3 master build the crash is in the following piece of code (seems to be different from the place in crash report):

http://opengrok.libreoffice.org/xref/core/sw/source/core/text/widorp.cxx#68

if( !m_bKeep && m_pFrame->IsInSct() )
{
    const SwSectionFrame* const pSct = m_pFrame->FindSctFrame();
    m_bKeep = pSct->Lower()->IsColumnFrame() && !pSct->MoveAllowed( m_pFrame );
}

m_pFrame->FindSctFrame() returns nullptr, which it shouldn't.
Comment 13 Xisco Faulí 2017-03-03 10:00:20 UTC
This is the crash report I get in

Versión: 5.3.0.3
Id. de compilación: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
Subpr. de CPU: 1; Versión de SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; 
Configuración regional: es-ES (es_ES); Calc: group

http://crashreport.libreoffice.org/stats/crash_details/480f139f-52c3-45db-96e0-6f772332d6f3

and this one in 

Version: 5.4.0.0.alpha0+
Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18
Locale: es-ES (es_ES); Calc: group

http://crashreport.libreoffice.org/stats/crash_details/5f3ac3b9-31de-4ad8-99db-b1292cb03f34
Comment 14 Xisco Faulí 2017-03-03 10:25:55 UTC
Created attachment 131597 [details]
gdb backtrace
Comment 15 510jrb2301 2017-03-16 15:12:54 UTC
AMDG

Thank you everyone for helping.  The file still crashes on me (under Ubuntu 16.04).  Let me work on it a little more.  In case I cannot stabilize the file, I'll return to comment.  For now will you keep the bug open as unresolved.
Comment 16 Aron Budea 2017-03-17 07:18:57 UTC
Let's reset status to NEW, and also bump priority. The bug requires code fix.
Comment 17 Aron Budea 2017-05-04 15:55:38 UTC
Adding Xisco's crash report signature to the field.
Comment 18 Xisco Faulí 2017-05-19 14:30:54 UTC
easiest way to reproduce the crash:

1. Open the document
2. Insert a header


Reproduced in

Version: 5.5.0.0.alpha0+
Build ID: fa89a464ca9c76332f533da0ab641da5acd00b52
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-05-19_01:24:56
Locale: es-ES (es_ES); Calc: group
Comment 19 Michael Stahl 2017-05-31 13:41:25 UTC
can't reproduce a crash on current master, i get (on Linux) some infinite layout loop instead, and immediately after loading too, no need to click or insert anything

crash in comment #12 and comment #14 and
http://crashreport.libreoffice.org/stats/crash_details/480f139f-52c3-45db-96e0-6f772332d6f3
is the same as bug 107126 which is fixed now

(also removing wrong dataLoss keyword)
Comment 20 Xisco Faulí 2017-05-31 14:15:43 UTC
(In reply to Michael Stahl from comment #19)
> can't reproduce a crash on current master, i get (on Linux) some infinite
> layout loop instead, and immediately after loading too, no need to click or
> insert anything
> 
> crash in comment #12 and comment #14 and
> http://crashreport.libreoffice.org/stats/crash_details/480f139f-52c3-45db-
> 96e0-6f772332d6f3
> is the same as bug 107126 which is fixed now
> 
> (also removing wrong dataLoss keyword)

Hi Michael,

Could you try my steps from comment 18 ?


1. Open the document
2. Insert a header

I can still reproduce the crash in

Version: 5.5.0.0.alpha0+
Build ID: 9956849c2ea6049582e2ccf04c355542c1ef00a1
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

Crash Report: crashreport.libreoffice.org/stats/crash_details/4e3fe4e3-70d8-4cf7-9010-b1537252291b
Comment 21 Michael Stahl 2017-06-08 13:58:11 UTC
as said i'm unable to insert a header on Linux

but can reproduce it on Windows

nope previous comment #19 was wrong, this is a different crash

in SwFootnoteBossFrame::MoveFootnotes_():
the pFootnote->GetRef() is a SwTextFrame below SwBodyFrame below SwColumnFrame below SwSectionFrame
"this" is a column frame
but the pRefBoss is a SwPageFrame ?

SwFrame::FindFootnoteBossFrame() -> 1-column and not IsFootnoteAtEnd() -> redirect to page frame

previously the footnote container was in a column in a section, now it's outside the section, but the mbInfSct flags inside the footnotes are not reset
Comment 22 Xisco Faulí 2017-06-10 11:54:24 UTC
Another way to reproduce the crash:
1. Open the file
2. Go to the Navigator ( F5 )
3. Expand Heading section
4. Select the first heading
5. Click on 'Demote chapter' button

Crash Report: http://crashreport.libreoffice.org/stats/crash_details/784f1bb0-d915-439b-92f4-9234c8a60cbb
Comment 23 Commit Notification 2017-06-22 08:15:51 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#101821 sw: layout: don't move endnotes into footnotes' container

It will be available in 6.0.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 24 Commit Notification 2017-06-22 08:16:02 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#101821 sw: fix layout footnote use-after-free

It will be available in 6.0.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 25 Commit Notification 2017-06-22 08:16:11 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#101821 sw: fix another layout footnote use-after-free

It will be available in 6.0.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 26 Commit Notification 2017-06-22 12:40:16 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#101821 sw: fix layout footnote use-after-free in SwRootFrame

It will be available in 6.0.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 27 Michael Stahl 2017-06-22 20:01:14 UTC
looks like i was wrong about the layout loop, the layout does indeed never
finish and hog the CPU, but if you are more patient than i was initially
you can modify the document (probably it's easier if you don't use a
slow --enable-dbgutil build).

the section has the m_bEndnAtEnd flag set - this causes it to be created with a SwColumnFrame despite only 1 column.

there is a single 1-column section covering the entire bugdoc.

there are endnotes but not footnotes in bugdoc.

crash is caused by: FindFootnoteBossFrame is called wrongly with bFootnotes=true for a endnote, then it is placed in the endnote SwFootnoteContFrame instead of the page's

... and then i asked valgrind and it reported a couple of user-after-frees ...

the crash is fixed on master, the layout still there but that's a separate bug :)
Comment 28 Commit Notification 2017-06-23 14:08:37 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d4a041fe81b36e1e8f933bfe4216afcea72c76d&h=libreoffice-5-3

tdf#101821 sw: fix layout footnote use-after-free in SwRootFrame

It will be available in 5.3.5.

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 29 510jrb2301 2017-06-23 14:21:02 UTC
AMDG

Many thanks to everyone but especially to Michael Stahl for resolving the problems.  I'm looking forward to using the update.

May I suggest an addition which could be helpful.  I note that the file takes some time to load completely.  The temptation to start editing the file before say the endnotes are loaded could be perilous.  It would be helpful in my opinion to set a "loading banner" which would lock out the user until the file is completely loaded.

Finally how can I get a copy of the recovered file?

Again many thanks for your focused attention on this problem 

JRB
Comment 30 Commit Notification 2017-06-23 14:35:29 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=93c3f32a029becc259ace4230f0f814a1ac66945&h=libreoffice-5-4

tdf#101821 sw: fix layout footnote use-after-free in SwRootFrame

It will be available in 5.4.0.2.

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 31 Aron Budea 2017-06-25 04:51:55 UTC
(In reply to 510jrb2301 from comment #29)
> Finally how can I get a copy of the recovered file?

There's no recovered file, the original should be openable without a crash with the fixed versions. In terms of release versions that would be 5.3.5 and 5.4.0, both are roughly a month away.

In the meantime you could give it a try with a daily build available at [1]. Steps of installing it in parallel without disrupting an existing installation are detailed in [2].

[1] http://dev-builds.libreoffice.org/daily/master/
[2] https://wiki.documentfoundation.org/Installing_in_parallel
Comment 32 Commit Notification 2017-07-04 10:27:43 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=67f60fb315d8a7f235034bf2960ffb939033fcc4&h=libreoffice-5-4

tdf#101821 sw: layout: don't move endnotes into footnotes' container

It will be available in 5.4.0.2.

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 33 Commit Notification 2017-07-04 10:29:01 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d34d70eb928f6818d9f68f1da07673ce48f90ea&h=libreoffice-5-3

tdf#101821 sw: layout: don't move endnotes into footnotes' container

It will be available in 5.3.5.

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 34 Commit Notification 2017-07-04 10:30:27 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d95ac92b8530b0a48b468862b722daa88215228e&h=libreoffice-5-4

tdf#101821 sw: fix layout footnote use-after-free

It will be available in 5.4.0.2.

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 35 Commit Notification 2017-07-11 15:42:09 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f8b32e4388cfc9cfcf1acebc82d023a8d3783463&h=libreoffice-5-3

tdf#101821 sw: fix layout footnote use-after-free

It will be available in 5.3.5.

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 36 Pedro 2017-09-14 15:27:28 UTC
This bug is still not fixed. Just crashed LO 5.3.6 under Windows 7

The crash report was successfully uploaded.
You can soon find the report at:
crashreport.libreoffice.org/stats/crash_details/bb160c8d-84b6-43be-93d0-30271ea63328

and crashed LO 5.4.1 under Windows 7 x64

The crash report was successfully uploaded.
You can soon find the report at:
crashreport.libreoffice.org/stats/crash_details/9184aeb4-82db-40a3-8515-b9aadbceb281
Comment 37 Xisco Faulí 2017-09-14 15:43:24 UTC
(In reply to Pedro from comment #36)
> This bug is still not fixed. Just crashed LO 5.3.6 under Windows 7
> 
> The crash report was successfully uploaded.
> You can soon find the report at:
> crashreport.libreoffice.org/stats/crash_details/bb160c8d-84b6-43be-93d0-
> 30271ea63328
> 
> and crashed LO 5.4.1 under Windows 7 x64
> 
> The crash report was successfully uploaded.
> You can soon find the report at:
> crashreport.libreoffice.org/stats/crash_details/9184aeb4-82db-40a3-8515-
> b9aadbceb281

Could you please give the detailed steps to reproduce the crash?
I can't reproduce it in

Version: 6.0.0.0.alpha0+
Build ID: 383aab7ed63bf30931c1cf89138707d2228b5dce
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 38 Pedro 2017-09-14 16:02:06 UTC
(In reply to Xisco Faulí from comment #37)

> Could you please give the detailed steps to reproduce the crash?
> I can't reproduce it in
> 
> Version: 6.0.0.0.alpha0+
> Build ID: 383aab7ed63bf30931c1cf89138707d2228b5dce
> CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
> Locale: ca-ES (ca_ES.UTF-8); Calc: group

Just opening the document and scrolling and clicking on a page will cause the crash but for a faster method, open the document and press Ctrl+End twice to jump to the very end of the document and wait. It will crash by itself before repagination ends (in my i7 2600 it takes less than one minute)
Comment 39 Timur 2017-09-14 17:17:48 UTC
I confirm the crash with 5.4.1:
http://crashreport.libreoffice.org/stats/crash_details/314be2c6-4a7b-4f4a-942e-751373b65e8a
But it looks different from this one.
And I couldn't have it with 6.0+, just temporary freeze.
And that old header multiple preview on scroll bug.