Why has Abrt (silently) ceased to enumerate CoreDumpCtl's entries?

coredumpctl list -r returns:

TIME                           PID  UID  GID SIG     COREFILE     EXE                                                                                  SIZE
Mon 2025-11-17 18:36:00 GMT 213587 1000 1000 SIGABRT present      /usr/bin/ksecretd                                                                  747.1K
Mon 2025-11-17 18:36:00 GMT 213513 1000 1000 SIGABRT present      /usr/libexec/xdg-desktop-portal-kde                                                  1.1M
Mon 2025-11-17 18:35:59 GMT 213466 1000 1000 SIGABRT present      /usr/libexec/xdg-desktop-portal-kde                                                  1.1M
Mon 2025-11-17 18:35:59 GMT 213376 1000 1000 SIGABRT present      /usr/libexec/xdg-desktop-portal-kde                                                  1.1M
Mon 2025-11-17 18:35:59 GMT 213362 1000 1000 SIGABRT present      /usr/libexec/xdg-desktop-portal-kde                                                  1.2M
Mon 2025-11-17 11:33:14 GMT  59864 1000 1000 SIGABRT present      /usr/libexec/xdg-desktop-portal-kde                                                  1.1M
Mon 2025-11-17 11:33:09 GMT  59600 1000 1000 SIGABRT present      /usr/libexec/drkonqi                                                               949.5K
Mon 2025-11-17 11:33:09 GMT  57961 1000 1000 SIGSEGV present      /usr/bin/plasmashell                                                                47.8M
Mon 2025-11-17 11:12:57 GMT  49848    0    0 SIGABRT inaccessible /tmp/.mount_QEFI.EoPhbil/usr/bin/QEFIEntryManager                                       -
Fri 2025-11-14 19:49:14 GMT   1776 1000 1000 SIGSEGV inaccessible /usr/bin/kwin_wayland                                                                   -

However, abrt list [1] returns, last:

Id           d0faaab  
Component    kwin  
Count        1  
Time         2025-11-14 19:49:14  
User id      1000 (RokeJulianLockhart)  
Reported to    
ABRT Server  https://retrace.fedoraproject.org/faf/reports/bthash/18fecf5fea800aa4d3e835efbe8f52f41e25f6c1  
Bugzilla     https://bugzilla.redhat.com/show_bug.cgi?id=2413512

  1. github.com/abrt/abrt/issues/1680 ↩︎

After having discussion.fedoraproject.org/t/162891 recur, this was remediated. However, now, abrt-2.17.7-1.fc43.x86_64 and gnome-abrt-1.4.3-8.fc43.x86_64 are in an inconsistent state:

  • abrt

    1. #!/usr/bin/env sh
      abrt list
      
    2. No problems

  • gnome-abrt

    [1] [2] [3]

    1. #!/usr/bin/env sh
      tree -a /var/spool/abrt/ccpp-2025-11-18-17:10:22.573990-14027
      
    2. .
      ├── abrt_version
      ├── analyzer
      ├── architecture
      ├── cgroup
      ├── cmdline
      ├── component
      ├── coredump
      ├── coredump.zst
      ├── count
      ├── cpuinfo
      ├── dso_list
      ├── environ
      ├── event_log
      ├── executable
      ├── exploitable
      ├── hostname
      ├── journald_cursor
      ├── kernel
      ├── last_occurrence
      ├── .libreport
      │   └── owner
      ├── limits
      ├── .lock -> 65072
      ├── maps
      ├── mountinfo
      ├── open_fds
      ├── os_info
      ├── os_release
      ├── package
      ├── pid
      ├── pkg_arch
      ├── pkg_epoch
      ├── pkg_fingerprint
      ├── pkg_name
      ├── pkg_release
      ├── pkg_vendor
      ├── pkg_version
      ├── proc_pid_status
      ├── pwd
      ├── reason
      ├── rootdir
      ├── runlevel
      ├── time
      ├── type
      ├── uid
      ├── username
      └── uuid
      
      2 directories, 46 files
      

  1. bugs.kde.org/show_bug.cgi?id=510982#c14 ↩︎

  2. github.com/ichaoX/ext-textFragment/issues/26#issuecomment-3543405918 ↩︎

  3. stackoverflow.com/questions/8768719/coredump-is-getting-truncated#comment140861241_60147685 [4] ↩︎

  4. unix.stackexchange.com/revisions/155482/1 ↩︎