+++ 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.