Bug 2211640 - Abrt does not report a segfault which is reported in journalctl.
Summary: Abrt does not report a segfault which is reported in journalctl.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: abrt
Version: 8.8
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: abrt
QA Contact: CS System Management SST QE
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On: 2128662
Blocks: F37FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2023-06-01 10:14 UTC by Martin Kyral
Modified: 2023-06-30 08:19 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 2128662
Environment:
Last Closed: 2023-06-30 08:19:10 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-158787 0 None None None 2023-06-01 10:16:20 UTC

Description Martin Kyral 2023-06-01 10:14:06 UTC
+++ This bug was initially created as a clone of Bug #2128662 +++

Description of problem:

Abrt does not show any notification, nor does it show and report a simulated segfault on Fedora 37 pre-Final (20220920).

The segmentation fault is correctly displayed in journalctl, which means that the system knows about it. 

Version-Release number of selected component (if applicable):
abrt-2.15.1-4
kernel 5.19.9-300

How reproducible:
Always

Steps to Reproduce:
1. Install the `will-crash` package that simulates various crashes.
2. Run `will_segfault` to simulate a segfault.
3. Wait for notifications -> none will come in 120 seconds
4. Open Abrt -> the segfault will not be displayed there.

Actual results:
Abrt might not be able to catch system issues which means that it cannot report them either.

Expected results:
Abrt should catch the issue, notify about it, show it in the application and allow to report it (or trace locally).

Additional info:

Journalctl has the info about the segfault:
---
Sep 21 12:41:09 platypus systemd-coredump[46119]: Process 46117 (will_segfault) of user 1000 dumped core.
                                                  
                                                  Module linux-vdso.so.1 with build-id 6daaf8b06a8e9606d0faa8151c085374ea451a22
                                                  Module ld-linux-x86-64.so.2 with build-id 653dfb54d6e6d9c27c349f698a8af1ab86d5501d
                                                  Module libc.so.6 with build-id a6572cd46182057d3dbacf1685a12edab0e2eda1
                                                  Module libwillcrash.so with build-id d17a8ed3a0098089a90ecaa1fd2c2dd21a85341f
                                                  Metadata for module libwillcrash.so owned by FDO found: {
                                                          "type" : "rpm",
                                                          "name" : "will-crash",
                                                          "version" : "0.13.5-2.fc37",
                                                          "architecture" : "x86_64",
                                                          "osCpe" : "cpe:/o:fedoraproject:fedora:37"
                                                  }
                                                  
                                                  Module will_segfault with build-id fc7b52fa0e3611a64622a30d94b5bdd4a86e4d9b
                                                  Metadata for module will_segfault owned by FDO found: {
                                                          "type" : "rpm",
                                                          "name" : "will-crash",
                                                          "version" : "0.13.5-2.fc37",
                                                          "architecture" : "x86_64",
                                                          "osCpe" : "cpe:/o:fedoraproject:fedora:37"
                                                  }
                                                  
                                                  Stack trace of thread 46117:
                                                  #0  0x000055abb5664262 crash.constprop.0 (will_segfault + 0x1262)
                                                  #1  0x000055abb5664335 varargs (will_segfault + 0x1335)
                                                  #2  0x000055abb566436e f (will_segfault + 0x136e)
                                                  #3  0x000055abb566439d callback (will_segfault + 0x139d)
                                                  #4  0x00007ff0dca8113d call_me_back (libwillcrash.so + 0x113d)
                                                  #5  0x000055abb5664232 recursive.constprop.0 (will_segfault + 0x1232)
                                                  #6  0x000055abb56640f6 main (will_segfault + 0x10f6)
                                                  #7  0x00007ff0dc8b7510 __libc_start_call_main (libc.so.6 + 0x23510)
                                                  #8  0x00007ff0dc8b75c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x235c9)
                                                  #9  0x000055abb5664155 _start (will_segfault + 0x1155)
                                                  ELF object binary architecture: AMD x86-64
Sep 21 12:41:09 platypus systemd[1]: systemd-coredump: Deactivated successfully.
---


--- Additional comment from Michal Srb on 2022-10-19 05:47:33 UTC ---

Thanks ;)

Indeed, I also see the problem on freshly installed f37 RC. It seems like the problem goes away when:

* systemd-coredump reports a crash in journal
* abrt-journal-core.service or the whole system is restarted

I.e. abrt-journal-core.service somehow doesn't see the first crash (or crashes before first restart after them). 

I see the same error in journal:

Oct 18 11:13:22 fedora abrt-dump-journal-core[792]: Cannot save journal watch's position

I am wondering if abrt-journal-core.service is somehow incorrectly initializing the journal cursor, if there are no prior (valid) crashes in journal.
I think I have an idea when the problem might be. Another fix incoming today.


Note You need to log in before you can comment on or make changes to this bug.