This bug was filed from the crash reporting server and is br-e376e7a6-f9e8-4cfd-9616-c9a7766c7b80. ========================================= 1. Open attachment 144106 [details] 2. CTRL+A & CTRL+C 3. CTRL+N (New document) 4. CTRL+V 5. Delete the image on the last page (Éric (Perrineau) (in the new document) 6. CTRL+X 7. CTRL+Z 3 times (back to initial blank document) 8. CTRL+V 9. CTRL+A 10. CTRL+X
1. Open attachment 144106 [details] 2. CTRL+A & CTRL+C 3. CTRL+N (New document) 4. CTRL+V 5. CTRL+X 6. CTRL+Z (twice) 7. CTRL+V 8. CTRL+X 9. CTRL+Z twice??
Reproduced with 1. Open attachment 144106 [details] 2. CTRL+A & CTRL+C 3. CTRL+N (New document) 4. CTRL+V 5. CTRL+A 6. CTRL+X 7. CTRL+Z (twice) 8. CTRL+V 9. CTRL+A 10. CTRL+X CRASH!! Version: 6.2.0.0.alpha0+ Build ID: 53eda574a61396b6765cd1cb0ac9804c754ac4c1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
The issue started in GTK3 after https://cgit.freedesktop.org/libreoffice/core/commit/?id=962e0bb4b31265b046fe4fb57d3087e20f5fe4ef
(In reply to Xisco Faulí from comment #3) > The issue started in GTK3 after > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=962e0bb4b31265b046fe4fb57d3087e20f5fe4ef @Caolán, any idea why it's crashing?
I can reproduce it back to Version: 4.2.0.0.alpha1+ Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 but not in Version: 4.1.0.0.alpha1+ Build ID: a2c9d4f8bbde97f175bae4df771273a61251f40 it needs to be bisected with bibisect-42max repo
Created attachment 144156 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I don't reproduce this but had an assert at step 8 of Xisco's step by step process.
(In reply to Xisco Faulí from comment #2) > Reproduced with > > 1. Open attachment 144106 [details] > 2. CTRL+A & CTRL+C > 3. CTRL+N (New document) > 4. CTRL+V > 5. CTRL+A > 6. CTRL+X > 7. CTRL+Z (twice) > 8. CTRL+V > 9. CTRL+A > 10. CTRL+X > > CRASH!! This seems to have begun at the below commit. Adding Cc: to Michael Stahl ; Could you possibly take a look at this one? Thanks 8a8b50772859fd6198e8e139ca853a4b7aca9133 is the first bad commit commit 8a8b50772859fd6198e8e139ca853a4b7aca9133 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 22:42:31 2015 +0800 source-hash-b8002169336b6b7597d32755e41fa3dc2688539e commit b8002169336b6b7597d32755e41fa3dc2688539e Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Wed Nov 6 16:36:04 2013 +0100 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Thu Nov 7 14:27:50 2013 -0600 remove INPATH and PROEXT - WORKDIR path is just workdir - INSTDIR path is just instdir - WORKDIR_FOR_BUILD is workdir_for_build - INSTDIR_FOR_BUILD is instdir_for_build - replace other usage of INPATH by combination of OS and CPUNAME Change-Id: Ie398387ebd82a968ec2605f2103c55b43a231482 Reviewed-on: https://gerrit.libreoffice.org/6601 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Michael Stahl <mstahl@redhat.com>
the bisect result is wrong, that repo was IIRC incrementally built so the guilty commit is older than the found one. (might be worth looking at other bugs that have the same bisect result to see if there is a "likely" commit that looks suspicious? do we have another bibisect repo for that release?)
(In reply to Michael Stahl (CIB) from comment #8) > the bisect result is wrong, that repo was IIRC incrementally built so the > guilty commit is older than the found one. > > (might be worth looking at other bugs that have the same bisect result to > see if there is a "likely" commit that looks suspicious? do we have another > bibisect repo for that release?) Removing 'bisected' keyword
Still reproducible in Version: 6.4.0.0.alpha0+ Build ID: 2812610f4f39ed5892da08864893c758325d1d39 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
Still crashing, however the initial exact steps don't work anymore. It's still in the area of cut, paste/ undo/redo. However I get a bit restless to figure out the very precise steps. Crash signature maybe slightly different too swlo!SwNodes::UpdateOutlineIdx Version: 7.0.0.0.alpha0+ (x64) Build ID: 4501a0ba623ad61c5a4e0b807da2e96f0e4ce82c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Created attachment 159507 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I still got an assertion at the same step 8 from Xisco's reproduction process.
Created attachment 159508 [details] Valgrind trace
Created attachment 159511 [details] Valgrind trace The previous Valgrind trace was with a build containing enable-dbgutil + gtk3 rendering. This time, I got the crash at the end of Xisco's process but I used another build with enable-symbols (not enable-dbgutil) + gen rendering.
*** Bug 132164 has been marked as a duplicate of this bug. ***
Can the priority by increased a little. Assert + Crash 1,5 years old.. And I end up here every time I fiddle around with a random document pressing +/- CTRL+Z 3 times (see bug 132164). Or use attachment 139976 [details] Do a CTRL+V CTRL+Z dance an go down
(In reply to Telesto from comment #16) > Can the priority by increased a little. > Assert + Crash 1,5 years old.. And I end up here every time I fiddle around > with a random document pressing +/- CTRL+Z 3 times (see bug 132164). Or use > attachment 139976 [details] Do a CTRL+V CTRL+Z dance an go down When you say a random document, you mean with any document you try ? we have 516 crashes in https://crashreport.libreoffice.org/stats/signature/CompareSwOutlineNodes::operator()(SwNode%20*%20const%20&,SwNode%20*%20const%20&) which is not that much considering it's been around for years now. seems more like a corner case to me
(In reply to Xisco Faulí from comment #17) > (In reply to Telesto from comment #16) > > Can the priority by increased a little. > > Assert + Crash 1,5 years old.. And I end up here every time I fiddle around > > with a random document pressing +/- CTRL+Z 3 times (see bug 132164). Or use > > attachment 139976 [details] Do a CTRL+V CTRL+Z dance an go down > > When you say a random document, you mean with any document you try ? It's rather 'easy' to reproduce in the sense of finding crashing document. OTOH, the steps needed are quite unlikely to happen in real life. So, technically a corner case.. The annoying parts is that, when I 'testing' the stability.. without exactly monitoring my steps, I get a crash caused by this bug. And attaching WinDBG showing another crash cause.. However, bug 116640 is referring to the same commit.. with 5000 crashes in the past. https://crashreport.libreoffice.org/stats/signature/SwNode::FindTableNode() -> Can that one be bumped in priority?
*** Bug 134626 has been marked as a duplicate of this bug. ***
*** Bug 134780 has been marked as a duplicate of this bug. ***
*** Bug 137050 has been marked as a duplicate of this bug. ***
Opting for Inherited based on bug 134626 comment 10
Steps from comment 2 still reproducible in Version: 7.2.0.0.alpha0+ Build ID: 480d00625534c356dabd96c503d992f07c99d152 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
The fix for bug #121546 fixes this (as per the comment #2 reproducer route), I can't speak for all the duplicates. *** This bug has been marked as a duplicate of bug 121546 ***