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?
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).
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
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
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.
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
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.
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.
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
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.
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
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.
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
Created attachment 131597 [details] gdb backtrace
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.
Let's reset status to NEW, and also bump priority. The bug requires code fix.
Adding Xisco's crash report signature to the field.
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
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)
(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
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
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
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.
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.
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.
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.
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 :)
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.
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
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.
(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
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.
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.
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.
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.
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
(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
(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)
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.
(In reply to Timur from comment #39) > 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. Reported in bug 122081