I reproduced this crash while trying to reproduce bug 95941 Since both crashreport signatures are different, I report this crash in a different report. Steps to reproduce: 1. Open attachment 120673 [details] from bug 95941 2. Delete the Index in page 3 3. Close the document with or without saving
Confirming with: Version: 5.4.0.0.alpha0+ Build ID: 4354f0e9ef4a5538729a2a6f2d1745e247f6c5cd CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-04-21_06:05:57 Locale: nl-NL (nl_NL); Calc: CL and with: Version: 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale: nl-NL (nl_NL) but not with: Versie: 4.4.6.3 Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d Locale: nl_NL
Regression introduced by: author Michael Stahl <mstahl@redhat.com> 2016-06-09 13:52:16 (GMT) committer Michael Stahl <mstahl@redhat.com> 2016-06-09 13:59:19 (GMT) 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
Created attachment 132802 [details] backtrace
Michael: Following Xisco's comment (https://bugs.documentfoundation.org/show_bug.cgi?id=107398#c2), I put you in cc.
unsurprisingly this is not a regression from the commit in comment #2, LO 5.0.6 crashes in the same way. versions 4.4.7.2, 4.3.7.2, 4.2.8.2 dont appear to crash for me.
bibisected with 50-max, started to crash somewhere in the 5.0 idle-timer refactoring: commit 9e678c14e4fc8e58b1e0530744f648fa3958d338 is good commit d05a64df34fd143670cb939b72abfb32d6b714c7 is bad
(In reply to Michael Stahl from comment #6) > bibisected with 50-max, > started to crash somewhere in the 5.0 idle-timer refactoring: > > commit 9e678c14e4fc8e58b1e0530744f648fa3958d338 is good > commit d05a64df34fd143670cb939b72abfb32d6b714c7 is bad You are right: # possible first bad commit: [18afb8632caa524fbc70ed5ce3808e23e5dad16f] source-hash-d05a64df34fd143670cb939b72abfb32d6b714c7 # possible first bad commit: [891b689ba95b9e53609194ee2a1a2d3b8955843c] source-hash-01f406bc28f53acc5a2734af637aa8074a5d1813
Created attachment 132859 [details] backtrace
Wow - did you bisect it down to just one commit: git log -u 01f406bc28f53acc5a2734af637aa8074a5d1813..d05a64df34fd143670cb939b72abfb32d6b714c7 Shows me a single commit from Tobias =) JMux - any ideas ?
i think this might be a pre-existing condition in the layout that was masked previously by running the idle layout always from a timer; now it doesn't run again until something is edited. warn:legacy.osl:7770:1:sw/source/core/layout/flowfrm.cxx:2406: <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move Backward> applied! warn:legacy.osl:7770:1:sw/source/core/layout/ftnfrm.cxx:958: Content without footnote. so if you edit the page styles "Default Style" and "ChapterStart", on the Footnote tab, switch the separator style from [None] to Single, it becomes apparent that (after deleting the index) on page 19 there is a footnote separator but no footnote below it, while page 20 has several footnotes.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e15b8997f0d2e54fa7b8345063755616d0b100b9 tdf#107398 sw: do not leave empty footnote container in layout It will be available in 5.4.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.
Verified in Version: 5.4.0.0.alpha0+ Build ID: 7c11fe076005ed4e28f04f14990b7011a03a4517 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group
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=27bbee974eaf59f722c115c9717faa8c74b9d815&h=libreoffice-5-3 tdf#107398 sw: do not leave empty footnote container in layout It will be available in 5.3.4. 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-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=253a345ccd0bd499950759c792da62fe9dc437ee&h=libreoffice-5-3-3 tdf#107398 sw: do not leave empty footnote container in layout It will be available in 5.3.3. 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.
Simplify targets content.