Bug 2307278

Proposing as Final blocker, this bug violates final criterion: Default application functionality - problem reporter

Discussed during the 2024-08-26 blocker review meeting: [1]

The decision to classify this bug as a AcceptedBlocker (Final) and AcceptedFreezeException (Beta) was made:

"this is accepted as a violation of the "basic functionality" criterion for the crash reporter app. We also accept it as a Beta FE as this is significant functionality for Beta testing, the value of Beta testing is lessened if this does not work."

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-08-26/f41-blocker-review.2024-08-26-16.00.log.html

From journal:

Aug 31 19:33:11 fedora abrt-dump-journal-core[1089]: Failed to obtain all required information from journald
Aug 31 19:33:11 fedora abrt-server[7282]: Package 'coreutils' isn't signed with proper key
Aug 31 19:33:11 fedora abrt-server[7282]: 'post-create' on '/var/spool/abrt/ccpp-2024-08-31-19:33:11.7355-7256' exited with 1
Aug 31 19:33:11 fedora abrt-server[7282]: Deleting problem directory '/var/spool/abrt/ccpp-2024-08-31-19:33:11.7355-7256'


If seems like the signature information is now stored in a different place in the RPM headers:

$ rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE} %|SIGGPG?{%{SIGGPG:pgpsig}}:{%{SIGPGP:pgpsig}}|\n' kernel
kernel-6.8.5-301.fc40 RSA/SHA256, Fri 12 Apr 2024 12:09:20 AM CEST, Key ID 0727707ea15b79cc
kernel-6.10.7-200.fc40 (none)
kernel-6.11.0-0.rc5.43.fc41 (none)

This works:

$ rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE} %|DSAHEADER?{%{DSAHEADER:pgpsig}}:{%|RSAHEADER?{%{RSAHEADER:pgpsig}}:{%|SIGGPG?{%{SIGGPG:pgpsig}}:{%|SIGPGP?{%{SIGPGP:pgpsig}}:{(none)}|}|}|}|\n' kernel
kernel-6.8.5-301.fc40 RSA/SHA256, Fri 12 Apr 2024 12:09:20 AM CEST, Key ID 0727707ea15b79cc
kernel-6.10.7-200.fc40 RSA/SHA256, Fri 30 Aug 2024 06:37:04 AM CEST, Key ID 0727707ea15b79cc
kernel-6.11.0-0.rc5.43.fc41 RSA/SHA256, Mon 26 Aug 2024 12:05:11 AM CEST, Key ID d0622462e99d6ad1

FEDORA-2024-7daecea5d6 (abrt-2.17.6-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-7daecea5d6

FEDORA-2024-7daecea5d6 (abrt-2.17.6-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-c374a9dcaa (abrt-2.17.6-1.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-c374a9dcaa

FEDORA-2024-6198bb5a57 (abrt-2.17.6-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-6198bb5a57

This need to wait for f41 push...

FEDORA-2024-6198bb5a57 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6198bb5a57`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6198bb5a57

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-c374a9dcaa has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-c374a9dcaa`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-c374a9dcaa

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I have installed the latest updates from the repository above and I am still experiencing the issue.

To test, I have typed (as advised in Abrt documentation): 

sleep 1m & kill -SIGSEGV $!

In coredumpctl, the crash is visible as:

~~~
Mon 2024-09-02 13:30:38 CEST 152028 1000 1000 SIGSEGV present  /usr/bin/bash                  549.9K
~~~

The details being:

~~~
           PID: 152028 (bash)
           UID: 1000 (lruzicka)
           GID: 1000 (lruzicka)
        Signal: 11 (SEGV)
     Timestamp: Mon 2024-09-02 13:30:38 CEST (2min 41s ago)
  Command Line: /bin/bash
    Executable: /usr/bin/bash
 Control Group: /user.slice/user-1000.slice/user/app.slice/vte-spawn-7acf66b3-6bba-494c-a54d-1215333a9bc9.scope
          Unit: user
     User Unit: vte-spawn-7acf66b3-6bba-494c-a54d-1215333a9bc9.scope
         Slice: user-1000.slice
     Owner UID: 1000 (lruzicka)
       Boot ID: a4b97a27af6f4db680a0ea10c44fcc26
    Machine ID: ac07ba047d6b4cd3b5459ad92f9c4e37
      Hostname: vseved
       Storage: /var/lib/systemd/coredump/core.bash.1000.a4b97a27af6f4db680a0ea10c44fcc26.152028.1725276638000000.zst (present)
  Size on Disk: 549.9K
       Package: bash/5.2.32-1.fc41
      build-id: ede570e17e0f792c96147d5c13b4c3ed12c90d6a
       Message: Process 152028 (bash) of user 1000 dumped core.
                
                Module libtinfo.so.6 from rpm ncurses-6.5-2.20240629.fc41.x86_64
                Module bash from rpm bash-5.2.32-1.fc41.x86_64
                Stack trace of thread 152028:
                #0  0x00007f93fec98fcb kill (libc.so.6 + 0x19fcb)
                #1  0x000055a765fc2fb0 kill_shell (bash + 0x5cfb0)
                #2  0x000055a765fc6a08 termsig_handler.part.0 (bash + 0x60a08)
                #3  0x000055a765f8e794 execute_simple_command.lto_priv.0 (bash + 0x28794)
                #4  0x000055a765f8286d execute_command_internal (bash + 0x1c86d)
                #5  0x000055a765f83bf2 execute_command_internal (bash + 0x1dbf2)
                #6  0x000055a765f8515e execute_command (bash + 0x1f15e)
                #7  0x000055a765f76b28 reader_loop (bash + 0x10b28)
                #8  0x000055a765f6a587 main (bash + 0x4587)
                #9  0x00007f93fec82248 __libc_start_call_main (libc.so.6 + 0x3248)
                #10 0x00007f93fec8230b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x330b)
                #11 0x000055a765f6b285 _start (bash + 0x5285)
                ELF object binary architecture: AMD x86-64
~~~

Abrt does not report anything, and it does not show it, either. After the installation, I have restarted the abrtd.service.

@lruzicka Your output shows that it's the "bash" that was killed, not the sleep command.

Try this please:

$ sleep 1m &
[2] 5485
$ kill -SIGSEGV $!
[2]+  Segmentation fault      (core dumped) sleep 1m

@msrb 

I tried this and now the catch is shown in journalctl, it is also visible in Abrt, but there is no notification shown in Gnome.

~~~
zář 02 14:45:51 vseved abrt-notification[166798]: [🡕] Process 166648 (sleep) crashed in clock_nanosleep.5()
~~~

@lruzicka Notifications work for me. However, I've noticed this behavior in the past: if you update abrt, and immediately after that try to test it, the notification may not appear. abrtd kills the old abrt-dbus before it starts, and I suspects that there might be some delay before it reconnects again.

If you want to be sure, I recommend simply restarting the system after you update abrtd.

Yeah, after having restarted the system, the notifications have appeared and they seem to be working.

I verify that the above update solves the problem.

Maybe you can karma it, then? I will try and test it tomorrow.

FEDORA-2024-c374a9dcaa (abrt-2.17.6-1.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-6198bb5a57 (abrt-2.17.6-1.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.