Created attachment 108442 [details] Demo file that systematically triggers the issue. Problem description: Note: version in which I am seeing the bug is in fact 4.3.3.2 (the bug submission assistante does not list it yet). I see the bug on ubuntu trusty, with the LibO distribution from libreoffice.org. Steps to reproduce: 1. Install LibO 4.3.3.2 (personally trying with a *new* profile/config dir) 2. Assure that you have Languagetool 2.7 installed 3. Open a file with a drawing 4. Close libreoffice Current behavior: On LibO closing one gets # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f714e65aa1c, pid=14141, tid=140124706691200 # # JRE version: OpenJDK Runtime Environment (7.0_65-b32) (build 1.7.0_65-b32) # Java VM: OpenJDK 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea 2.5.3 # Distribution: Ubuntu 14.04 LTS, package 7u71-2.5.3-0ubuntu0.14.04.1 # Problematic frame: # C [libvcllo.so+0x2e9a1c] ImpBitmap::~ImpBitmap()+0xc Expected behavior: Libreoffice should never segfault. Notes: I do not see the issue if I uninstall Languagetool. However, Languagetool is a java tool. Thus the bug may be merely related to the fact that the presence of Languagetool causes Libreoffice to load java from the very start.
Note: bug submitted from freedesktop. It is currently impossible to submit bugs using the LibO bug submission assistant that always replies "Data not yet loaded. Please press submit again in a few seconds."
yes, the BSA in temporarily out of service.
Good to see you knew already about the BSA, sorry for the noise. For the real issue, I have also tried to cross-post to the Languagetool forum.
Cannot reproduce on a 32 bit ubuntu utopic machine Differences wrt the machine where I systematically see the issue Machine where I have the issue 64bit kubuntu Trusty Machine where I do not see the issue 32bit ubuntu Utopic
Please, ignore my previous message on machines where the bug is not triggered. It may contain incorrect information and I will need to test further. In fact, weirdly, the crash seems to be triggered only when one passes through the Libreoffice splash screen and I did not notice this fact in my previous tests. E.g. 1) libreoffice [enter] => splash screen opens 2) open file via File->open or by clicking on thumbnail => file opens 3) File->exit => crash or 1) libreoffice <file> => file opens 2) File->Close => file closes, splash screen appears 3) File->exit => crash but 1) libreoffice <file> => file opens 2) File->exit => no crash Now, I see this on the following two machines: 1) Kubuntu trusty 64bit, intel 2) Kubuntu utopic 64bit, amd
Could not reproduce this on 64 bit Ubuntu 14.04 with LO 4.3.3.2 and recent 4.4 master, with or without LanguageTool installed Valgrind memcheck didn't show anything interesting either (it rather disapproves of java's JIT compilation, but excluding everything that appears to relate to that there are no unexplained invalid reads / writes) One possibility that suggests itself is that it is somehow specific to what is displayed in the start centre
Strange, because every single machine I have now seems to show the issue. As a matter of fact, it is most likely related to the initial launcher. I am in fact noticing that in some cases it is enough to start libreoffice, see the laucher screen with the small document thumbnails and close libreoffice without doing anything else to see the crash. Then, if I erase all the documents in the launcher, I do not see the crash in this way. Are you sure you have languagetool installed? If I disable languagetool 2.7 I do not see the crash. In any case, it really looks like the problem is confined to the laucher. My only wish would be to be able to disable the laucher to avoid filling my home with crash reports and most important to avoid the ubuntu crash report tool firing up all the time. Let me try to recap how I systematically see the issue: 1) Install languagetool I suspect it has nothing to do with the issue, but by causing java to load early it may trigger it. 2) start libreoffice with libreoffice watermark.odt and immediately exit it. This is in order to put the demo file in the launcher screen. At the exit there should be no issue. 3) start libreoffice with libreoffice in order to open the launcher 4) click on the watermark document thumbnail to open it 5) close libreoffice see the crash.
Looks like I finally have a first ubuntu machine where I do *not* see the issue. I'll try to find out what is different.
OK! I have finally sorted this out (I think). Libreoffice crashes when quitting the application in certain conditions. These include - having something on the launch screen - having Languagetool installed - not having the gnome integration package installed Since the actual trigger consists in not having the gnome integration package installed, I have updated the bug title accordingly. In this respect note that: - Gnome integration has never been compulsory before. Among the Libreoffice packages there are both a kde-integration package and a gnome-integration package. Until recently, it was possible to install just kde-integration on kde systems and just gnome-integration in gnome. Now, without gnome-integration, Libreoffice is prone to crashes. - Installing gnome integration is an obvious workaround for the crash. However, it is very undesirable since it creates multiple problems of its own. Specifically: a) If one has both gnome-integration and kde-integration installed, Libreoffice should be smart enough to recognize the environment it is running in and pick the suitable integration flavor. Conversely, if one has gnome-integration installed, libreoffice always assumes that gnome integration is to be used, even if kde integration is also installed and one is under kde. b) With gnome integration on, unless the system *forces* some dpi, Libreoffice always seems to assume 96 dpi, completely ignoring what the system reports with xdpyinfo and randr. Since every other application on the system uses the dpi value reported by xdpyinfo and randr, this completely breaks the integration with the desktop, making the libreoffice fonts invariably look too huge or too tiny. Of course this can be worked around by configuring libreoffice to use a scaling factor for its interface... but why? As a conclusion, please restore the former behavior where libreoffice could work without the gnome-integration package in kde. And assure that the lack of an integration package at most results in an error presented to the user, not in a misterious segfault and core dump.
Can someone (Matthew Francis, maybe) please try without the gnome-integration package installed and see if the bug can now be reproduced? Otherwise, I will try to investigate further...
On pc Debian x86-64 with 4.3.3 LO Debian package, I don't reproduce this whereas I installed LanguageTool 2.7 and uninstalled gnome-integration.
Would it be possible you attach a backtrace by following this link: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace ?
Created attachment 109421 [details] Backtrace of segfault Backtrace log from 4.3.4.1 on kubuntu utopic 64 bit, kde environment, gnome-integration package not installed.
When launching Libreoffice with the --backtrace option, the segfault is anticipated. I do not see it when closing the application, but when opening the test file from the launcher.
The bad aspect is that with --backtrace the segfault happens in the same way even with the gnome integration installed.
Created attachment 109424 [details] libreoffice log at crash
Created attachment 109425 [details] strace log
Could you generate hs_err_pid... again but after having typed this: ulimit -c unlimited as suggested in file hs_err_pid17022.log ?
Created attachment 109457 [details] hs_error_pid with ulimit -c unlimited
Done!
I reproduce this on Ubuntu 14.04 / LO 4.3.4.1 with LanguageTool installed and libobasis4.3-gnome-integration uninstalled -> NEW
Created attachment 109515 [details] Ubuntu 14.04 backtrace None of the previously attached backtraces obviously contain the actual crash other than the top frame at ImpBitmap::~ImpBitmap() The attached isn't much of a backtrace either but it's what's there. The root cause is clearly somewhere much earlier. Incidentally, no file was required to achieve this crash - just starting LO to the start centre then quitting.
Also occurs on a fresh build of 4.4 master. To reproduce without having to do anything to the standard test install, run: SAL_USE_VCLPLUGIN=gen instdir/program/soffice.bin then just quit as before
Can't even launch LO with this option, I get this crash with master sources updated yesterday: terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException' Program received signal SIGABRT, Aborted. 0x00002aaaab29f107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 0x00002aaaab29f107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00002aaaab2a04e8 in __GI_abort () at abort.c:89 #2 0x00002aaaabc9cb3d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00002aaaabc9abb6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00002aaaabc9ac01 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00002aaaabc9ae19 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00002aaaac971cb7 in comphelper::getProcessServiceFactory () at /home/julien/compile-libreoffice/libreoffice/comphelper/source/processfactory/processfactory.cxx:64 #7 0x00002aaaac972076 in comphelper::getProcessComponentContext () at /home/julien/compile-libreoffice/libreoffice/comphelper/source/processfactory/processfactory.cxx:96 #8 0x00002aaabf40e50e in SalDisplay::BestVisual (pDisplay=0x64b6d0, nScreen=0, rVI=...) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/saldisp.cxx:194 #9 0x00002aaabf40f3cb in SalDisplay::initScreen (this=0x656a20, nXScreen=...) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/saldisp.cxx:431 #10 0x00002aaabf407439 in SalDisplay::getDataForScreen (this=0x656a20, nXScreen=...) at /home/julien/compile-libreoffice/libreoffice/vcl/inc/unx/saldisp.hxx:331 #11 0x00002aaabf431208 in SalDisplay::GetScreenSize (this=0x656a20, nXScreen=...) at /home/julien/compile-libreoffice/libreoffice/vcl/inc/unx/saldisp.hxx:338 #12 0x00002aaabf42b08e in vcl_sal::WMAdaptor::WMAdaptor (this=0x658a00, pDisplay=0x656a20) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/wmadaptor.cxx:242 #13 0x00002aaabf42b5b1 in vcl_sal::NetWMAdaptor::NetWMAdaptor (this=0x658a00, pSalDisplay=0x656a20) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/wmadaptor.cxx:336 #14 0x00002aaabf42ae1d in vcl_sal::WMAdaptor::createWMAdaptor (pSalDisplay=0x656a20) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/wmadaptor.cxx:188 #15 0x00002aaabf40ffb3 in SalDisplay::Init (this=0x656a20) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/saldisp.cxx:616 #16 0x00002aaabf40f196 in SalX11Display::SalX11Display (this=0x656a20, display=0x64b6d0) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/saldisp.cxx:389 #17 0x00002aaabf40b24b in SalXLib::Init (this=0x63f380) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/saldata.cxx:463 #18 0x00002aaabf40aa76 in X11SalData::Init (this=0x6361e0) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/saldata.cxx:293 #19 0x00002aaabf424117 in create_SalInstance () at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/app/salinst.cxx:61 #20 0x00002aaab14ef490 in tryInstance (rModuleBase="gen", bForce=true) at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/plugadapt/salplug.cxx:69 #21 0x00002aaab14efb35 in CreateSalInstance () at /home/julien/compile-libreoffice/libreoffice/vcl/unx/generic/plugadapt/salplug.cxx:227 #22 0x00002aaab13a565e in InitVCL () at /home/julien/compile-libreoffice/libreoffice/vcl/source/app/svmain.cxx:261
After poking around at this with gdb for a bit, I think what is happening is that the VCL plugin that's backing the SalBitmap in question has somehow been unloaded before the destructor of the SalBitmap is called - it hasn't been destroyed before the crash, but rather the memory range behind the pointer has become invalid
The bug corresponding to the bt I retrieved may be fixed by http://cgit.freedesktop.org/libreoffice/core/commit/?id=34c1c41817212ca95117cbd1fe582b180007945c
Possible fix: https://gerrit.libreoffice.org/#/c/12469/1
In case the possible fix actually fixes the issue, can it be marked for 4.3.4.2?
there won't be a 4.3.4.2 release. the 4.3.4 RC1 is already a final. an eventual port of the fix could go in 4.3.5 https://wiki.documentfoundation.org/ReleasePlan/4.3#4.3.4_release
Since Matthew submitted a fix to gerrit and assigned himself to this bugtracker.
Matthew J. Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e43f692ef908fd2bc180a5e16fb363ec6bb7eb09 fdo#85478 Avoid destroying bitmaps after VCL is shut down It will be available in 4.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
No backport to the 4.3 series, then? No mercy for a poor series that will find out when it is still so young that it gonna keep segfaulting on this through the whole of its life?
Matthew, I tried a cherry-pick of your patch on 4.3, there's no conflict, any chance to backport it?
4.3 branch is EOL and the patch is there on 4.4.0 (anyway 4.4 branch is soon EOL). So this one can be considered as FIXED now.