Description: calc crash often observed upon exit after having saved a modified sheet Steps to Reproduce: 1.open an existing sheet 2.modify some cells 3.press SAVE icon 4.close the window with X on the top right corner Actual Results: calc crash Expected Results: nothing should crash Reproducible: Sometimes User Profile Reset: No Additional Info: Version: 7.0.3.1 Build ID: 00(Build:1) CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Ubuntu package version: 1:7.0.3-0ubuntu0.20.10.1 Calc: threaded
profile has been reset and bug is still here
Created attachment 170116 [details] debug trace
*** This bug has been marked as a duplicate of bug 140677 ***
Mariosv: why do you consider this as a dup? Indeed debug trace seems pure qt5 pb whereas tdf#140677 can be reproduced in gtk3 (I don't reproduce tdf#104677 myself). I've updated my local repo and it's building right now but I'll give a try to this one with kf5 rendering.
Pascal: on pc Debian x86-64 with master sources updated today + kf5 rendering, I don't reproduce this. Do you reproduce this with a brand new file? Do you reproduce this with an existing file which just contains "test" in A1? Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps ? If you still reproduce this, could you try this: - open terminal/console - export SAL_USE_VCLPLUGIN=gen - launch Calc and give a new try ?
Too much similarity, but only a supposition on my side. You can know better than me.
I don't reproduce this with kf5 rendering too. I can't help here=>uncc myself.
well since I have installed dbg packages to complete symbol resolution in backtrace, I cannot reproduce the crash anymore... putting in standby until I can.
Adding bug 137139 to see also
Created attachment 170140 [details] same crash but with writer I had 3 crash with writer closing a modified saved doc this morning, one of which is the same as the one I send yesterday with closing calc. The 2 other crashes are identical to each other but not the same as the one here.
Does that happen with specific documents only? Can you share one and try to give more hints on how to potentially reproduce more reliably? While it's of course ideal to have steps to reproduce 100 % reliably for further analysis, steps to reproduce "somewhat reliably" are also very helpful already. This sounds very much like tdf#137139, but I hadn't been able to provoke such a crash back then when testing for a while.
Created attachment 170179 [details] test document try to change some already existing cells in this calc then save with the save button then exit with the X in the window corner it might take some tries before it crashes at exit
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Pascal from comment #12) > Created attachment 170179 [details] > test document > > try to change some already existing cells in this calc > then save with the save button > then exit with the X in the window corner > > it might take some tries before it crashes at exit Thanks, I tried more than 20 times but it didn't crash here. Can you possibly attach a screencast? (In reply to Pascal from comment #10) > Created attachment 170140 [details] > same crash but with writer > > I had 3 crash with writer closing a modified saved doc this morning, one of > which is the same as the one I send yesterday with closing calc. > The 2 other crashes are identical to each other but not the same as the one > here. Interesting, the backtrace also shows 'ScSelectionTransferObj::~ScSelectionTransferObj', which is clearly Calc-related. Did you have any other documents open in addition to the Writer one? And/Or have you copied data from Calc to somewhere else previously?
OK you might have found the mechanism ! You must be on Kubuntu (maybe) You setup klipper to only have an history count of 1 (paste buffer history count) you start calc you open the joined doc you select a few cells in it you press ctrl-c (to copy) then you close the calc window with the X on the corner => crash
bugs #140728 #140698 might be related to the same trigger problem
(In reply to Pascal from comment #15) > OK you might have found the mechanism ! > > You must be on Kubuntu (maybe) > You setup klipper to only have an history count of 1 (paste buffer history > count) > > you start calc > you open the joined doc > you select a few cells in it > you press ctrl-c (to copy) > > then you close the calc window with the X on the corner > => crash Great, thanks! I used cells D7 to F12 for selection and can reproduce this now with LO as provided in Debian testing (package libreoffice 1:7.0.4-3) with the steps from comment 15: Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-GB (en_GB.UTF-8); UI: en-GB Debian package version: 1:7.0.4-3 Calc: threaded but not with a self-compiled LibreOffice master debug build Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: c7b898df4d452746399621f6adc8e7da088f0f3a CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded And it doesn't crash when setting Klipper history size to 2 instead.
Turns out that it did not always crash with the steps from comment 15, but adding an extra step made it always crash with affected versions for me: 1) setup klipper to only have an history count of 1 (paste buffer history count) 2) start calc 3) open attachment 170179 [details] 4) select cells D7 to F12 5) press ctrl-c (to copy) 6) open "Help" -> "About LibreOffice" 7) copy version information, then close the "About dialog" again 8) close LO using the "X" button on the top right Result of bibisecting with libreoffice-7-2 repo shows that the crash has been fixed by this commit already: commit 20305894243e24eb383ab9feefebf4a0e9f2644f Author: Mike Kaganski <mike.kaganski@collabora.com> Date: Sun Feb 14 11:24:42 2021 +0100 nullptr dereference Change-Id: I6a2ffddfd67784ddc2194dafba7d3eaeb6e4e12e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110854 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Cherry-picks for LibreOffice 7.0 and 7.1 now pending in Gerrit: https://gerrit.libreoffice.org/c/core/+/112084 https://gerrit.libreoffice.org/c/core/+/112083
*** Bug 137139 has been marked as a duplicate of this bug. ***
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/f5f5582fa065000a187a92b47ca44498d1f30c09 tdf#140700 nullptr dereference It will be available in 7.1.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/ef41f5d2106b68544a078bfac85018e37cab90d1 tdf#140700 nullptr dereference It will be available in 7.0.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.