This bug was filed from the crash reporting server and is br-f32b07bc-c39c-4ddc-b8ea-1f1d7c39ec29. ========================================= 1. Open attachment 43973 [details] (bug 34876) 2. Select all (CTRL+A) 3. Delete everything 4. Undo delete (CTRL+Z)
I can't reproduce it in Version: 5.5.0.0.alpha0+ Build ID: 7662b11cad6105d56fb9acc9c431c89d3b68dc89 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-20_10:09:09 Locale: es-ES (es_ES); Calc: group
1. Open attachment 43973 [details] (bug 34876) 2. Select all (CTRL+A two times) 3. Delete everything (delete) 4. Undo delete (CTRL+Z) Version: 5.5.0.0.alpha0+ Build ID: d57e6cd9dcc96112994ca2b14ac45896e86b26e5 CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-05-18_22:43:07 Locale: nl-NL (nl_NL); Calc: CL
Another way to create the crash: 1. Open http://oval.mitre.org/language/version5.10.1/OVAL_Unix_Component_Specification.04-04-2012.docx 2. Immediately press CTRL+A twice or three (four) times after the document opens up (while pagination is still in the process).
(In reply to Telesto from comment #2) > 1. Open attachment 43973 [details] (bug 34876) > 2. Select all (CTRL+A two times) > 3. Delete everything (delete) > 4. Undo delete (CTRL+Z) > > Version: 5.5.0.0.alpha0+ > Build ID: d57e6cd9dcc96112994ca2b14ac45896e86b26e5 > CPU threads: 4; OS: Windows 6.19; UI render: default; > TinderBox: Win-x86@42, Branch:master, Time: 2017-05-18_22:43:07 > Locale: nl-NL (nl_NL); Calc: CL no crash here (In reply to Telesto from comment #3) > Another way to create the crash: > 1. Open > http://oval.mitre.org/language/version5.10.1/ > OVAL_Unix_Component_Specification.04-04-2012.docx > 2. Immediately press CTRL+A twice or three (four) times after the document > opens up (while pagination is still in the process). Yes, it's true I get a crash here, but I get a different craskreport everytime: - http://crashreport.libreoffice.org/stats/signature/SwFrame::GetFrameAnchorPos(bool) - http://crashreport.libreoffice.org/stats/signature/SwFrame::ImplFindPageFrame() so IMHO, I wouldn't consider these steps acceptable.
Created attachment 133627 [details] Example file Same steps (as reported at first); new document.
I was reproduced by "attachment 133627 [details]" in the following environment. I was not reproduced by "attachment 43973 [details]". OS: Debian jessie x86-64 Version: 5.5.0.0.alpha0+ Build ID: 9ad56da72a79a2d649755a0ab98bd53f238db08b CPU threads: 4; OS: Linux 3.16; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-05-27_23:12:59 Locale: en-US (ja_JP.utf8); Calc: group
I was not reproduced by "attachment 133627 [details]" in the following environment. OS: Debian jessie x86-64 Version: 5.3.3.2 Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU Threads: 4; OS Version: Linux 3.16; UI Render: default; VCL: gtk2; Layout Engine: new; Locale: en-US (ja_JP.utf8); Calc: group However, i repeat the reproduction procedure again, i can not delete it in step 3 and the following message will be displayed "Write-protected content cannot be changed."
(In reply to Telesto from comment #5) > Created attachment 133627 [details] > Example file > > Same steps (as reported at first); new document. Using that document I can reproduce the crash in Version: 5.5.0.0.alpha0+ Build ID: 7662b11cad6105d56fb9acc9c431c89d3b68dc89 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-05-20_10:09:09 Locale: es-ES (es_ES); Calc: group but not in Versión: 5.3.2.2 Id. de compilación: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 Subproc. CPU: 1; SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; Configuración regional: es-ES (es_ES); Calc: group However, on Linux I can reproduce it back to Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 Maybe it's crashing in different points depending on the OS...
I can't reproduce it in Version: 5.3.3.2 Build ID: 1:5.3.3~rc2-0ubuntu0.16.10.1~lo0 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: ca-ES (ca_ES.UTF-8); Calc: group Strange...
Created attachment 133735 [details] gdb backtrace
Regression introduced in: author Bjoern Michaelsen <bjoern.michaelsen@canonical.com> 2017-02-27 23:04:14 (GMT) committer Björn Michaelsen <bjoern.michaelsen@canonical.com> 2017-02-28 09:03:41 (GMT) commit 912b30b36114a9f52e87b3154e6512056b90873a (patch) tree a71b52ab19036ef5759dc7d1764d913050f20f3e parent a0bdcc5578e77b1122f533c62550d5e5f9290f1b (diff) use a vector of unique_ptr for explicit memory management Bisected with bibisect-linux-64-5.4 Adding Cc: to Bjoern Michaelsen
Havent looked too deep into this yet, but given the strange behaviour in comment 8 and comment 9, this possibly isnt caused by the commit, rather its a "was broken before, but wasnt crashing immediately due to sheer luck then" ...
From the stacktrace: #1 0xe00dbcf4 in SwFrame::FindFlyFrame (this=0x0) at /home/buildslave/source/libo-core/sw/source/core/inc/frame.hxx:938 #2 0xe05281af in SwPageFrame::AppendDrawObjToPage (this=this@entry=0xde4a4464, _rNewObj=...) at /home/buildslave/source/libo-core/sw/source/core/layout/flylay.cxx:804 So "this" in FindFlyFrame at #1 is a nullptr, which means "_rNewObj.GetAnchorFrame()" at #2 (flylay.cxx:804) is a nullptr, which: > OSL_ENSURE( _rNewObj.GetAnchorFrame(), "anchored draw object without anchor" ); in the line before says should never happen anyway.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2ca0360a6c75959bf61bd2ee0ef96b2729369a15 tdf#108118 sw: fix recursive layouting during SwCursorShell::Paint() It will be available in 5.5.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.
guess this is a pre-existing problem, it's tricky to reproduce because it's timing-dependent, the comment #3 with repeatedly pressing Ctrl+A worked for me fixed on master
Confirming fix with: Version: 5.5.0.0.alpha0+ Build ID: 076ed447f694239d5c67adee528ea6e471d909ff CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-09_23:54:20 Locale: nl-NL (nl_NL); Calc: CL Thanks!
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=55631479120c94224196a3d4703cf2f8c705071b&h=libreoffice-5-4 tdf#108118 sw: fix recursive layouting during SwCursorShell::Paint() It will be available in 5.4.0.1. 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=9fa193f1a17eac56c19f611c76c2cdd022487b9e&h=libreoffice-5-3 tdf#108118 sw: fix recursive layouting during SwCursorShell::Paint() 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.