Bug 85478 - Libreoffice 4.3.3 segfaults on closing when gnome-integration is not installed
Summary: Libreoffice 4.3.3 segfaults on closing when gnome-integration is not installed
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.3.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Matthew Francis
URL:
Whiteboard: target:4.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-26 11:14 UTC by sergio.callegari
Modified: 2015-10-18 10:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Demo file that systematically triggers the issue. (13.21 KB, application/vnd.oasis.opendocument.graphics)
2014-10-26 11:14 UTC, sergio.callegari
Details
Backtrace of segfault (20.51 KB, text/x-log)
2014-11-13 14:49 UTC, sergio.callegari
Details
libreoffice log at crash (113.34 KB, text/x-log)
2014-11-13 14:58 UTC, sergio.callegari
Details
strace log (992.37 KB, application/x-xz)
2014-11-13 15:00 UTC, sergio.callegari
Details
hs_error_pid with ulimit -c unlimited (121.11 KB, text/x-log)
2014-11-14 11:46 UTC, sergio.callegari
Details
Ubuntu 14.04 backtrace (908 bytes, text/plain)
2014-11-15 11:09 UTC, Matthew Francis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2014-10-26 11:14:29 UTC
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.
Comment 1 sergio.callegari 2014-10-26 11:16:08 UTC
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."
Comment 2 tommy27 2014-10-26 12:44:08 UTC
yes, the BSA in temporarily out of service.
Comment 3 sergio.callegari 2014-10-26 13:19:36 UTC
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.
Comment 4 sergio.callegari 2014-10-26 19:44:14 UTC
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
Comment 5 sergio.callegari 2014-10-28 10:43:14 UTC
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
Comment 6 Matthew Francis 2014-10-29 12:20:53 UTC
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
Comment 7 sergio.callegari 2014-11-03 11:06:34 UTC
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.
Comment 8 sergio.callegari 2014-11-04 18:07:41 UTC
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.
Comment 9 sergio.callegari 2014-11-04 23:57:34 UTC
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.
Comment 10 sergio.callegari 2014-11-06 16:23:01 UTC
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...
Comment 11 Julien Nabet 2014-11-11 11:45:27 UTC
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.
Comment 12 Julien Nabet 2014-11-11 11:45:52 UTC
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 ?
Comment 13 sergio.callegari 2014-11-13 14:49:11 UTC
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.
Comment 14 sergio.callegari 2014-11-13 14:50:10 UTC
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.
Comment 15 sergio.callegari 2014-11-13 14:52:29 UTC
The bad aspect is that with --backtrace the segfault happens in the same way even with the gnome integration installed.
Comment 16 sergio.callegari 2014-11-13 14:58:37 UTC
Created attachment 109424 [details]
libreoffice log at crash
Comment 17 sergio.callegari 2014-11-13 15:00:28 UTC
Created attachment 109425 [details]
strace log
Comment 18 Julien Nabet 2014-11-13 15:14:12 UTC
Could you generate hs_err_pid... again but after having typed this:
ulimit -c unlimited
as suggested in file hs_err_pid17022.log ?
Comment 19 sergio.callegari 2014-11-14 11:46:26 UTC
Created attachment 109457 [details]
hs_error_pid with ulimit -c unlimited
Comment 20 sergio.callegari 2014-11-14 11:53:04 UTC
Done!
Comment 21 Matthew Francis 2014-11-15 10:12:21 UTC
I reproduce this on Ubuntu 14.04 / LO 4.3.4.1 with LanguageTool installed and libobasis4.3-gnome-integration uninstalled

-> NEW
Comment 22 Matthew Francis 2014-11-15 11:09:33 UTC
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.
Comment 23 Matthew Francis 2014-11-15 12:04:55 UTC
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
Comment 24 Julien Nabet 2014-11-15 12:47:25 UTC
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
Comment 25 Matthew Francis 2014-11-15 12:57:22 UTC
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
Comment 26 Julien Nabet 2014-11-15 15:55:30 UTC
The bug corresponding to the bt I retrieved may be fixed by
http://cgit.freedesktop.org/libreoffice/core/commit/?id=34c1c41817212ca95117cbd1fe582b180007945c
Comment 27 Matthew Francis 2014-11-16 03:05:29 UTC
Possible fix: https://gerrit.libreoffice.org/#/c/12469/1
Comment 28 sergio.callegari 2014-11-16 09:16:39 UTC
In case the possible fix actually fixes the issue, can it be marked for 4.3.4.2?
Comment 29 tommy27 2014-11-16 09:38:16 UTC
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
Comment 30 Julien Nabet 2014-11-16 09:42:23 UTC
Since Matthew submitted a fix to gerrit and assigned himself to this bugtracker.
Comment 31 Commit Notification 2014-11-17 09:58:21 UTC
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.
Comment 32 sergio.callegari 2014-11-17 13:11:59 UTC
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?
Comment 33 Julien Nabet 2014-11-17 19:21:41 UTC
Matthew, I tried a cherry-pick of your patch on 4.3, there's no conflict, any chance to backport it?
Comment 34 Julien Nabet 2015-10-18 10:33:32 UTC
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.