Description: Crash PolyPolygon Steps to Reproduce: 1. open attachment 162564 [details]' 2. CTRL+A 3. Set font size to 80 4. Press Undo Actual Results: Crash Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: c48e4d795e37f23b71d647247590807ab9e52223 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 162607 [details] BT without symbols
Would like a proper BT (if reproducible).. if this is the real PolyPolygon mystery bug
Created attachment 162610 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
Second attempt for a PolyPolygon reproducer Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault. 0x00007fffef631a08 in __gnu_cxx::__atomic_add (__mem=0x100000007, __val=1) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/ext/atomicity.h:53 53 { __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); } (gdb) bt #0 0x00007fffef631a08 in __gnu_cxx::__atomic_add(int volatile*, int) (__mem=0x100000007, __val=1) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/ext/atomicity.h:53 #1 0x00007fffef6319b9 in __gnu_cxx::__atomic_add_dispatch(int*, int) (__mem=0x100000007, __val=1) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/ext/atomicity.h:96 #2 0x00007fffef6323e3 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_add_ref_copy() (this=0xffffffff) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/shared_ptr_base.h:139 #3 0x00007fffef632c34 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::operator=(std::__shared_count<(__gnu_cxx::_Lock_policy)2> const&) (this=0x7ffffffec838, __r=...) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/shared_ptr_base.h:747 #4 0x00007fffefef6b42 in std::__shared_ptr<tools::PolyPolygon, (__gnu_cxx::_Lock_policy)2>::operator=(std::__shared_ptr<tools::PolyPolygon, (__gnu_cxx::_Lock_policy)2> const&) (this=0x7ffffffec830) at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/shared_ptr_base.h:1168
Not in Version: 6.4.0.0.beta1+ (x64) Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Created attachment 162612 [details] Valgrind trace
Created attachment 162615 [details] Bibisect log Bisected to author Armin Le Grand <armin.le.grand@me.com> 2020-02-27 16:43:44 +0100 committer Armin Le Grand <Armin.Le.Grand@me.com> 2020-02-27 18:12:30 +0100 commit 424312aa99307da9f0ee60ea6e3213b2b3dc26b4 (patch) tree be71b53596bccdba919059799f56bec0412fa101 parent ab623953b92d82d615bd2af6a9369915fe6fb7a8 (diff) tdf#130768 Make tiled writer paint reuse decomposes See more info in comment 23 of task. Roughly it's about correcting a helper that led to destroying the View and thus the OC and thus the whole primitive buffering - what was expensive, for the case where decompositions were expensive https://cgit.freedesktop.org/libreoffice/core/commit/?id=424312aa99307da9f0ee60ea6e3213b2b3dc26b4
Adding CC: to Armin Le Grand
I get no crash. Do you have waited with "undo" until the formatting to new font size is finished?
(In reply to Regina Henschel from comment #9) > I get no crash. Do you have waited with "undo" until the formatting to new > font size is finished? Didn't matter to much for me.. Pressing undo at pag 500 something. Did you try a regular build or bibisect build or only a home build version. This bug has some timing element, i assume
(In reply to Telesto from comment #10) > Did you try a regular build or bibisect build or only a home build version. > This bug has some timing element, i assume Tested with Version: 7.1.0.0.alpha0+ (x64) Build ID: 913449e2ba8cea7d3eb1dbe1af93182fd5b85fd0 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL (own build) and with Version: 7.1.0.0.alpha0+ (x64) Build ID: 4c14c88cc681abab787a461a1bea502a777f37e6 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL ("offical" daily build from 30.June) and with Version: 6.4.5.0.0+ (x64) Build ID: 70a2071ce91b71326659e645dd97996262ea309a CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (en_US); UI-Language: en-US Calc: threaded No crash.
(In reply to Regina Henschel from comment #11) No clue, except I'm running Windows 8.1. It crashes as a clockwork for me.. And the STR seem to work for Julien..
I can reproduce it in Version: 7.1.0.0.alpha0+ (x64) Build ID: 616a47c9570f9ce67b18a124f08f4a342bff3468 CPU threads: 16; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
Also reproducible in Version: 7.1.0.0.alpha0+ Build ID: d851a02df57ab378ed0cc6d9362516de09c3279c CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I do confirm https://cgit.freedesktop.org/libreoffice/core/commit/?id=424312aa99307da9f0ee60ea6e3213b2b3dc26b4 introduced this issue, bisected with bibisect-linux64-7.0
I have encountered this bug quite number of times. See bug 132940. This might be even uncovering a different. BT looks similar to crash bug 134996. Goes back to 6.0
Sorry, I can't seem to trigger this crash
Created attachment 164461 [details] Screencast I press Undo while it's still processing they font 80 change
(In reply to Telesto from comment #18) > I press Undo while it's still processing they font 80 change I don't see you pressing any button? Are you using ctrl-Z? The Undo icon doesn't seem to enable until the operation is complete (for me). I can't repro this with master on Windows or on Linux-gtk3
(In reply to Noel Grandin from comment #19) > (In reply to Telesto from comment #18) > > I press Undo while it's still processing they font 80 change > > I don't see you pressing any button? Are you using ctrl-Z? The Undo icon > doesn't seem to enable until the operation is complete (for me). > > I can't repro this with master on Windows or on Linux-gtk3 I pressed CTRL+Z after I changed the font size. [Need to find a way to record also pressed keys in a screencast] Anyhow the crash is I assume a memory corruption. Access after deletion or something like that (bit BT is already about shared pointers) Anyhow.. this is actually only one out of number of options.. see bug 132940 (and also the see the list also there). It are all examples of the same problem as far I can tell; BT are slightly different; but always in the same area.
Pretty sure this is fixed with https://git.libreoffice.org/core/commit/445cf499666f21c2d480ce1df9ce6004b9450b64
Stable Version: 7.1.0.0.alpha0+ (x64) Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL