Download it now!
Bug 131083 - Calc crashes when marking cells and you exit without saving
Summary: Calc crashes when marking cells and you exit without saving
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2020-03-03 07:47 UTC by mgruber
Modified: 2020-10-22 06:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
This file crashes Calc when F10/F11 cells are marked (7.26 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-03-03 07:47 UTC, mgruber
Details
Calc right before closing via the white/gray X-button on the top right (89.00 KB, image/png)
2020-03-03 07:49 UTC, mgruber
Details
KCrash log (9.31 KB, text/plain)
2020-03-03 07:49 UTC, mgruber
Details
Kcrash log from debug build 45ca47ac39c03df4de52d627a764f16068b1eab0 (13.61 KB, text/plain)
2020-03-03 09:54 UTC, mgruber
Details
Memcheck Kcrash log (3.96 KB, text/plain)
2020-03-04 08:56 UTC, mgruber
Details
Valgrind log (110.80 KB, text/x-log)
2020-03-04 08:57 UTC, mgruber
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mgruber 2020-03-03 07:47:15 UTC
Description:
Calc crashes most likely due to a QT problem.

Steps to Reproduce:
Steps to reproduce:

1. Open the attached crash.ods in LibreOffice Calc.
2. Mark the cells F10/F11 as seen in Screenshot_20200302_before_crash.png.
3. Close Calc at the top right button.

Actual Results:
Crash

Expected Results:
Shouldn't crash.


Reproducible: Always


User Profile Reset: No



Additional Info:
I'm using LibreOffice 6.4.0-0ubuntu7 on Kubuntu Focal. See also the attached crash report from KDE Apport.
Comment 1 mgruber 2020-03-03 07:47:56 UTC
Created attachment 158326 [details]
This file crashes Calc when F10/F11 cells are marked
Comment 2 mgruber 2020-03-03 07:49:21 UTC
Created attachment 158327 [details]
Calc right before closing via the white/gray X-button on the top right
Comment 3 mgruber 2020-03-03 07:49:49 UTC
Created attachment 158328 [details]
KCrash log
Comment 4 mgruber 2020-03-03 07:51:53 UTC
Forgot to add step "4.) Choose not to save" in the inital description.
Comment 5 Xisco Faulí 2020-03-03 08:27:44 UTC
I can't reproduce it in

Version: 7.0.0.0.alpha0+
Build ID: 950e1aec0a984ce40a5038331f491272b51d41fa
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 6 Xisco Faulí 2020-03-03 08:29:00 UTC
BTW, if I open the file, select those celss and close Calc, it doesn't ask me to  save the document. is there any step missing ?
Comment 7 mgruber 2020-03-03 09:52:49 UTC
I need to correct myself:
The bug doesn't depend on crash.ods, all that's needed are marked cells.

Steps to reproduce:

1. Download the debug build 7.0.0.0.alpha0+ (950e1aec0a984ce40a5038331f491272b51d41fa) and extract it.
2. Run scalc, mark two cells vertically and exit scalc

I'll attach a kcrash log of the debug build, which should contain more useful information than the one I posted before.
Comment 8 mgruber 2020-03-03 09:54:49 UTC
Created attachment 158333 [details]
Kcrash log from debug build 45ca47ac39c03df4de52d627a764f16068b1eab0
Comment 9 mgruber 2020-03-03 09:58:04 UTC
Sorry for the confusion: I used 45ca47ac39c03df4de52d627a764f16068b1eab0 as debug build, not 950e1aec0a984ce40a5038331f491272b51d41fa.
Comment 10 mgruber 2020-03-03 10:03:16 UTC
@Xisco Faulí: The reason why you might not see the bug us that you're using a deskto environment with GTK3. I wasn't able to reproduce it on Xubuntu Focal as well, only with KDE/QT on Kubuntu Focal.

Here's my complete About output from LibreOffice:

Version: 7.0.0.0.alpha0+
Build ID: 45ca47ac39c03df4de52d627a764f16068b1eab0
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF-dbg, Branch:master, Time: 2020-03-01_20:21:25
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded
Comment 11 Michael Weghorn 2020-03-03 15:32:56 UTC
(In reply to mgruber from comment #10)
> @Xisco Faulí: The reason why you might not see the bug us that you're using
> a deskto environment with GTK3.

I cannot reproduce with a master build from today:

Version: 7.0.0.0.alpha0+
Build ID: e17224501e9f4f783d5be3f5aa9c7f6decd8a405
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

> I wasn't able to reproduce it on Xubuntu
> Focal as well, only with KDE/QT on Kubuntu Focal.

Was that the same computer and user, just with a different desktop environment selected on login, or another one?

Can you try whether starting LibreOffice with SAL_USE_VCLPLUGIN=gtk3 /path/to/soffice --calc makes any difference (the info in "About" -> "LibreOffice" should then mention "VCL: gtk3")?
Comment 12 Michael Weghorn 2020-03-03 15:34:17 UTC
(In reply to Xisco Faulí from comment #6)
> BTW, if I open the file, select those celss and close Calc, it doesn't ask
> me to  save the document. is there any step missing ?

And just like Xisco, I also don't get that question either.

@mgruber: Can you start with a clean user profile? Do you have any extensions or custom document templates in use?
Comment 13 mgruber 2020-03-03 16:44:26 UTC
This...

test@test-VirtualBox:~/Downloads/LibreOfficeDev_7.0.0.0.alpha0_Linux_x86-64_archive/program$ SAL_USE_VCLPLUGIN=gtk3 soffice --calc
javaldx: Could not find a Java Runtime Environment!
Please ensure that a JVM and the package libreoffice-java-common
is installed.
If it is already installed then try removing ~/.config/libreoffice/4/user/config/javasettings_Linux_*.xml
Warning: failed to read path from javaldx

...still results in the follwing About information:

Version: 6.4.0.3
Build-ID: 1:6.4.0-0ubuntu7
CPU-Threads: 4; BS: Linux 5.4; UI-Render: Standard; VCL: kf5; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded

I'm testing both Kubuntu and Xubuntu in a VM environment (VirtualBox 6.1.4).
Comment 14 mgruber 2020-03-03 16:58:53 UTC
Sorry, I messed up the path, here's the correct call:

test@test-VirtualBox:~/Downloads/LibreOfficeDev_7.0.0.0.alpha0_Linux_x86-64_archive/program$ SAL_USE_VCLPLUGIN=gtk3 ./soffice --calc

Version: 7.0.0.0.alpha0+
Build ID: 45ca47ac39c03df4de52d627a764f16068b1eab0
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF-dbg, Branch:master, Time: 2020-03-01_20:21:25
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded

No crashes in this configuration.
Comment 15 mgruber 2020-03-03 17:23:56 UTC
> Do you have any extensions or custom document templates in use?

No, it's a plain vanilla Kubuntu Daily ISO install with the latest updates as of today.

> Can you start with a clean user profile?

I just deleted .config/libreoffice and tested it with the Dev build.
It took me about 6 attempts before it crashed.

Then I deleted .config/libreoffice again and ran it with 6.4.0-0ubuntu7.
I need 3 attempts until it crashed.

The procedure is always the same: start Calc, mark F10/11 vertically and exit.
Comment 16 mgruber 2020-03-03 17:25:48 UTC
The crash log in attachment 158333 [details] is no help at all?
Comment 17 QA Administrators 2020-03-04 02:49:12 UTC Comment hidden (obsolete)
Comment 18 Michael Weghorn 2020-03-04 07:09:57 UTC
(In reply to mgruber from comment #16)
> The crash log in attachment 158333 [details] is no help at all?

It is of value, shows that something seems to go wrong when deleting Qt5MimeData's 'const css::uno::Reference<css::datatransfer::XTransferable> m_aContents' member. It's still hard to analyze without being able to reproduce oneself and say what is the root cause, but it looks like some memory-related issue (use after free,...).

Can you reproduce the issue when running

  ./soffice --calc --valgrind

and attach the output here? (Note that valgrind needs to be installed and LibreOffice will run much slower.)
Comment 19 mgruber 2020-03-04 08:56:16 UTC
Since ./soffice --calc --valgrind >> /tmp/valgrind.log didn't pipe the actual log output, I used the following call as suggested in the debug instructions wiki:

valgrind --tool=memcheck --num-callers=128 --trace-children=yes ./soffice --calc 2>&1 | tee /tmp/valgrind.log

Hope that was correct(?).

I needed 2 attempts with usual mark F10/11 & exit routine, then memcheck-amd64-linux crashed.
I'll attach the KCrash log for memcheck and the Valgrind log.

There was also some message coming up from KDE, that there's not enough memory to create a dump of the crashed process. I've given the VM 4GB, but I could double or even triple that if necessary.
Comment 20 mgruber 2020-03-04 08:56:42 UTC
Created attachment 158369 [details]
Memcheck Kcrash log
Comment 21 mgruber 2020-03-04 08:57:24 UTC
Created attachment 158370 [details]
Valgrind log
Comment 22 Michael Weghorn 2020-03-04 15:00:12 UTC
(In reply to mgruber from comment #19)
> Since ./soffice --calc --valgrind >> /tmp/valgrind.log didn't pipe the
> actual log output, I used the following call as suggested in the debug
> instructions wiki:
> 
> valgrind --tool=memcheck --num-callers=128 --trace-children=yes ./soffice
> --calc 2>&1 | tee /tmp/valgrind.log
> 
> Hope that was correct(?).

Yes, thanks.

The valgrind log shows an invalid read:

> ==14248== Thread 1:
> ==14248== Invalid read of size 8
> ==14248==    at 0x321E20A0: ScModule::GetSelectionTransfer() const (scmod.hxx:155)
> ==14248==    by 0x321E0E10: ScSelectionTransferObj::~ScSelectionTransferObj() (seltrans.cxx:151)
> ==14248==    by 0x321E0EBF: ScSelectionTransferObj::~ScSelectionTransferObj() (seltrans.cxx:161)
>
> [...]
>
> ==14248==    by 0x400964: main (main.c:47)
> ==14248==  Address 0x100 is not stack'd, malloc'd or (recently) free'd

Unfortunately, I see no explicit information like where memory was free'd etc., which could have helped even more in finding out what's going wrong.

I still can't reproduce myself yet, but given the valgrind log, let's set status to NEW.
Comment 23 Michael Weghorn 2020-03-04 16:59:41 UTC
Just tried to reproduce the issue in an Kubuntu Focal VM, but was unable to do so there as well and I also did not get any prompt to save when closing when taking these steps

* run 'libreoffice --calc'
* select cells F10 and F11 using mouse
* press Alt+F4 or the window's close button to close LibreOffice

The fact that you do get one suggests that the document is considered modified, so any potential additional step that triggers this might also be relevant for the issue. Any ideas?
Comment 24 mgruber 2020-03-04 18:06:40 UTC
(In reply to Michael Weghorn from comment #23)
> Just tried to reproduce the issue in an Kubuntu Focal VM, but was unable to
> do so there as well

How many attempts did you try?
At one point I've had Calc exit 8x smoothly before it crashed.
I know it's really odd that it doesn't crash predictably every time.

> and I also did not get any prompt to save when closing when taking these steps

Ignore that, that was a misconception of me when I initially created crash.ods.

> The fact that you do get one suggests that the document is considered
> modified, so any potential additional step that triggers this might also be
> relevant for the issue. Any ideas?

You can try to play around with other cells, typing some random stuff in, marking others and so on.

> Unfortunately, I see no explicit information like where memory was free'd etc., 

Is there anything I can configure in Valgrind to get these informations?
Comment 25 Michael Weghorn 2020-03-04 21:13:42 UTC
(In reply to mgruber from comment #24)
> How many attempts did you try?
> At one point I've had Calc exit 8x smoothly before it crashed.
> I know it's really odd that it doesn't crash predictably every time.

Probably 15-20 times.

> You can try to play around with other cells, typing some random stuff in,
> marking others and so on.

I did that, but - unfortunately in this case - it still didn't crash for me.

> > Unfortunately, I see no explicit information like where memory was free'd etc., 
> 
> Is there anything I can configure in Valgrind to get these informations?

No, Valgrind ususally prints that by itself if it has that information.

*Maybe*, taking more time to analyse the backtrace, valgrind output and related code in the qt5 VCL plugin (and maybe Qt library itself) might already be enough to get an understanding of what may be happening.

I personally have to say I currently can't really say whether I'll find that time soon, but if anybody else wants to take a look, please do.
Comment 26 mgruber 2020-03-05 09:20:09 UTC
I just invested an hour and installed a new VM based on todays Kubuntu Focal ISO.
-> Calc doesn't crash
Made the installed DEB packages identical to the one in my original test system.
-> Calc doesn't crash
Copied the LibreOffice config folder over from the original test system.
-> Calc doesn't crash

Overall I did like 40 to 50 Calc tests.

I'm consternated.
I setup the original test system on February 13th with the Kubuntu Focal ISO of that date just to see if switching from XFCE to KDE makes sense for me. I did nothing extraordinary, installed GIMP and did the package updates via Discovery. I remember seeing many QT related packages being updated since that time.

Although this shouldn't happen in theory when you update, I can only guess that there are some broken/old QT libraries on the original test system causing the crashes.

So, I think you can consider these crashes to be an odd situation created by the state of the OS, which is close to becoming stable but still in testing.
Comment 27 Michael Weghorn 2020-03-05 10:07:59 UTC
(In reply to mgruber from comment #26)
> Although this shouldn't happen in theory when you update, I can only guess
> that there are some broken/old QT libraries on the original test system
> causing the crashes.
> 
> So, I think you can consider these crashes to be an odd situation created by
> the state of the OS, which is close to becoming stable but still in testing.

Thanks a lot for doing more testing!

Given that, should we close that bug report as WORKSFORME for now?
(You can reopen or create a new bug report at any time should the issue reappear.)
Comment 28 mgruber 2020-03-06 06:42:49 UTC
Yes, that's probably the best solution. I might check the problem again before Focal becomes stable.
Comment 29 Michael Weghorn 2020-03-06 07:10:05 UTC
Alright.