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.
Created attachment 158326 [details] This file crashes Calc when F10/F11 cells are marked
Created attachment 158327 [details] Calc right before closing via the white/gray X-button on the top right
Created attachment 158328 [details] KCrash log
Forgot to add step "4.) Choose not to save" in the inital description.
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.
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 ?
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.
Created attachment 158333 [details] Kcrash log from debug build 45ca47ac39c03df4de52d627a764f16068b1eab0
Sorry for the confusion: I used 45ca47ac39c03df4de52d627a764f16068b1eab0 as debug build, not 950e1aec0a984ce40a5038331f491272b51d41fa.
@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
(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")?
(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?
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).
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.
> 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.
The crash log in attachment 158333 [details] is no help at all?
[Automated Action] NeedInfo-To-Unconfirmed
(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.)
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.
Created attachment 158369 [details] Memcheck Kcrash log
Created attachment 158370 [details] Valgrind log
(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.
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?
(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?
(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.
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.
(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.)
Yes, that's probably the best solution. I might check the problem again before Focal becomes stable.
Alright.