Bug 1343751

Summary:	Abrt/libreport doesn't "see" LibreOffice crashes
Product:	[Fedora] Fedora	Reporter:	Christian Stadelmann <fedora>
Component:	libreoffice	Assignee:	Stephan Bergmann <sbergman>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	24	CC:	caolanm, dhgutteridge, dtardon, erack, mstahl, sbergman
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-08-24 15:55:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Christian Stadelmann 2016-06-07 20:02:25 UTC

Description of problem:
I just had a libreoffice crash. Immediately after crashing, LibreOffice noticed that it has crashed and showed a document recovery dialog. I wanted to report this crash using gnome-abrt, but it didn't show any crash. Journalctl doesn't reveal anything related at this timestamp, so abrt/libreport didn't even get the crash.

Version-Release number of selected component (if applicable):
libreoffice-5.1.4.1-1.fc24.x86_64
gtk3-3.20.6-1.fc24.x86_64
abrt-2.8.1-1.fc24.x86_64
libreport-2.7.1-1.fc24.x86_64

How reproducible:
unclear

Additional info:
I don't know who is to blame here, but abrt/libreport works for crashes in other applications and has worked for LibreOffice on this machine before. If it were blocking LibreOffice crashes, I would at least see in my journal that the process crashed.

Comment 1 David Tardon 2016-06-08 08:17:08 UTC

abrt catches no crashes at all on my system. What I see in the journal is

systemd-coredump[24437]: Core Dumping has been disabled for process 24388 (oosplash).

Comment 2 Christian Stadelmann 2016-06-08 12:49:33 UTC

(In reply to David Tardon from comment #1)
> abrt catches no crashes at all on my system. What I see in the journal is
> 
> systemd-coredump[24437]: Core Dumping has been disabled for process 24388
> (oosplash).

That's a separate issue. In your case the coredump at least gets to systemd, which might be related to some changes in abrt integrating systemd-coredump on rawhide, though I don't know much about this.

In my case this message doesn't even show up. Neither systemd-coredump nor abrt seem to get any notification of this crash.

Comment 3 David H. Gutteridge 2016-06-26 23:55:09 UTC

(Adding myself to the CC list since I've encountered this problem too. LibreOffice 5.1.4.x under Fedora 24 is crashing on me where 5.0.x on Fedora 23 was more stable. Under Fedora 23, occasionally X would crash, which seemed to be related to an interaction with LibreOffice, but at least I got a backtrace for X. Under Fedora 24, LibreOffice is randomly crashing, but not taking X with it. Less annoying but more obscure.)

Comment 4 Christian Stadelmann 2016-06-27 08:06:04 UTC

(In reply to David H. Gutteridge from comment #3)
> (Adding myself to the CC list since I've encountered this problem too.
> LibreOffice 5.1.4.x under Fedora 24 is crashing on me where 5.0.x on Fedora
> 23 was more stable. Under Fedora 23, occasionally X would crash, which
> seemed to be related to an interaction with LibreOffice, but at least I got
> a backtrace for X. Under Fedora 24, LibreOffice is randomly crashing, but
> not taking X with it. Less annoying but more obscure.)

Btw: You may try https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux

Comment 5 Stephan Bergmann 2016-08-24 15:55:03 UTC

(In reply to Christian Stadelmann from comment #0)
> Description of problem:
> I just had a libreoffice crash. Immediately after crashing, LibreOffice
> noticed that it has crashed and showed a document recovery dialog. I wanted
> to report this crash using gnome-abrt, but it didn't show any crash.
> Journalctl doesn't reveal anything related at this timestamp, so
> abrt/libreport didn't even get the crash.

This is rather by design.  LibreOffice' soffice.bin process establishes a signal handler and handles certain signals by calling _exit with a special exit code indicating to the outer oosplah process that it shall restart soffice.bin.  This means that soffice.bin does not terminate from the signal, so abrt et al would never get notified about it.

(I wonder if we ever patched out any parts of LO's signal handling code in the past, so that all crashes would cause abnormal termination of soffice.bin?)

> Additional info:
> I don't know who is to blame here, but abrt/libreport works for crashes in
> other applications and has worked for LibreOffice on this machine before. If
> it were blocking LibreOffice crashes, I would at least see in my journal
> that the process crashed.

Various crashes take different routes through LO's---rather complex---signal handling code, and not all of them lead to the _exit call with special exit code explained above.  That's why some crashes /are/ visible to abrt et al.