Bug 140700 - calc crash at exit in ScSelectionTransferObj::~ScSelectionTransferObj (steps in comment 18)
Summary: calc crash at exit in ScSelectionTransferObj::~ScSelectionTransferObj (steps ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.2 target:7.0.6
Keywords:
: 137139 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-02-27 13:53 UTC by Pascal
Modified: 2021-03-08 12:58 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
debug trace (3.53 KB, text/plain)
2021-02-27 13:54 UTC, Pascal
Details
same crash but with writer (3.44 KB, text/plain)
2021-03-01 08:29 UTC, Pascal
Details
test document (14.66 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-03-02 12:47 UTC, Pascal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pascal 2021-02-27 13:53:05 UTC
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
Comment 1 Pascal 2021-02-27 13:53:33 UTC
profile has been reset and bug is still here
Comment 2 Pascal 2021-02-27 13:54:26 UTC
Created attachment 170116 [details]
debug trace
Comment 3 m.a.riosv 2021-02-27 14:14:19 UTC

*** This bug has been marked as a duplicate of bug 140677 ***
Comment 4 Julien Nabet 2021-02-27 15:39:57 UTC
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.
Comment 5 Julien Nabet 2021-02-27 17:09:23 UTC
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
?
Comment 6 m.a.riosv 2021-02-27 19:38:28 UTC
Too much similarity, but only a supposition on my side. 

You can know better than me.
Comment 7 Julien Nabet 2021-02-27 19:51:25 UTC
I don't reproduce this with kf5 rendering too.
I can't help here=>uncc myself.
Comment 8 Pascal 2021-02-27 20:58:35 UTC
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.
Comment 9 Telesto 2021-02-28 09:05:52 UTC
Adding bug 137139 to see also
Comment 10 Pascal 2021-03-01 08:29:58 UTC
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.
Comment 11 Michael Weghorn 2021-03-01 10:16:42 UTC
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.
Comment 12 Pascal 2021-03-02 12:47:24 UTC
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
Comment 13 QA Administrators 2021-03-03 03:54:14 UTC Comment hidden (obsolete)
Comment 14 Michael Weghorn 2021-03-04 08:53:36 UTC
(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?
Comment 15 Pascal 2021-03-08 07:46:05 UTC
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
Comment 16 Pascal 2021-03-08 07:48:19 UTC
bugs #140728 #140698 might be related to the same trigger problem
Comment 17 Michael Weghorn 2021-03-08 08:40:06 UTC
(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.
Comment 18 Michael Weghorn 2021-03-08 09:45:19 UTC
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
Comment 19 Michael Weghorn 2021-03-08 09:47:10 UTC
*** Bug 137139 has been marked as a duplicate of this bug. ***
Comment 20 Commit Notification 2021-03-08 12:56:29 UTC
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.
Comment 21 Commit Notification 2021-03-08 12:58:46 UTC
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.