[Bug] Generation of a backtrace for a "System" failure fails with "Failed to generate microreport from the problem data".

[RokeJulianLockhart]

An Example

When processed, I saw:

Details

Failed to generate microreport from the problem data

Unfortunately, abrt immediately deleted it, rather like discussion.fedoraproject.org/t/162891 describes (although more similarly to when it locates a duplicate). ¹

Environment

#!/usr/bin/env sh
rpm -qa | grep abrt

abrt-libs-2.17.6-4.fc42.x86_64
abrt-dbus-2.17.6-4.fc42.x86_64
python3-abrt-2.17.6-4.fc42.x86_64
abrt-2.17.6-4.fc42.x86_64
abrt-addon-kerneloops-2.17.6-4.fc42.x86_64
abrt-addon-pstoreoops-2.17.6-4.fc42.x86_64
abrt-addon-vmcore-2.17.6-4.fc42.x86_64
abrt-addon-xorg-2.17.6-4.fc42.x86_64
abrt-plugin-bodhi-2.17.6-4.fc42.x86_64
python3-abrt-addon-2.17.6-4.fc42.noarch
gnome-abrt-1.4.3-4.fc42.x86_64
abrt-gui-libs-2.17.6-4.fc42.x86_64
abrt-gui-2.17.6-4.fc42.x86_64
abrt-addon-ccpp-2.17.6-4.fc42.x86_64
abrt-tui-2.17.6-4.fc42.noarch
abrt-cli-2.17.6-4.fc42.x86_64
abrt-desktop-2.17.6-4.fc42.x86_64

Tangential

This is an example of when #378 (comment) might be useful, considering that it might pertain to bugzilla.redhat.com/show_bug.cgi?id=2391169#c0.

[RokeJulianLockhart]

#389 (comment)

I've had this reproduce again:

However, because abrt required > 2 mins to delete it, undermentioned are its logs, attached as oops-2025-08-28-14.24.25-3117-0.tar.gz:

.
├── abrt_version
├── analyzer
├── architecture
├── backtrace
├── cmdline
├── event_log
├── hostname
├── kernel
├── last_occurrence
├── .libreport
│   └── owner
├── os_info
├── os_release
├── proc_modules
├── reason
├── suspend_stats
├── time
└── type

2 directories, 17 files

However, the reason differs (of what I recall, libreport-plugin-kerneloops-2.17.15-5.fc42.x86_64 states what bugzilla.redhat.com/show_bug.cgi?id=1518943 describes.)