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.
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).
(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.
(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.)
(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
(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.