Created attachment 173828 [details] Screenshot of `gnome-abrt` displaying the 20+ crash logs. SUMMARY ------- Upon booting after a package update, I was met with: 1. 1 crash of `plasma-workspace`; 2. 1 crash of `browser-integration`; and: 3. 23 crashes of `browser-integration-host`. Each time this occurred, the system eventually froze, to the extent that neither switching to a TTY nor `SysReq` worked. This occurred for 2 boots (`01fe61d209b24be7bec51108ed9b06f1` and `31bcd8e103064c6aa5269026a0b691c5`), but didn't on the 3rd (`b0fe282b8df4441c97b6089019cde3fe`), which I'm reporting this from. STEPS TO REPRODUCE ------------------ This isn't reproducible anymore, but *everything* I did - relevant or irrelevant - is undermentioned, because I did exactly the same the 1st 2 times (and the 3rd, though): 1. [x] Update (`sudo dnf update`) and shutdown (`systemctl poweroff`, in my case) via `plasma-discover`. 2. [x] Boot the machine. 3. [x] Invoke `koi` via its `.desktop` file listed in Application Launcher. 4. [x] Invoke `firefox`. 5. [x] Either accept to report or "Restart" the crashing integrator. 5. [x] Invoke `gnome-abrt`. 6. [~] Attempt to generate a trace. OBSERVED RESULT --------------- Aforementioned in the summary - the OS hangs indefinitely, with significant (but variable) CPU load, per evident fan RPM increase. EXPECTED RESULT --------------- 1. The browser integrator, and especially Plasma itself, shouldn't have crashed. It definitely shouldn't have crashed that many times - there needs to be a point at which it undergoes permanent apoptosis so that I can at least acquire a stack trace (which can't be achieved after a reboot). 2. DrKonqi (and `gnome-abrt`, if it contributed) shouldn't have crashed the OS/DE with its 20+ automatic trace generators. SOFTWARE/OS VERSIONS -------------------- [`kinfo`](https://koji.fedoraproject.org/koji/rpminfo?rpmID=39683204) reports: > ```YAML > Operating System: Fedora Linux 40 > KDE Plasma Version: 6.1.4 > KDE Frameworks Version: 6.5.0 > Qt Version: 6.7.2 > Kernel Version: 6.10.10-200.fc40.x86_64 (64-bit) > Graphics Platform: Wayland > Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor > Memory: 30.5 GiB of RAM > Graphics Processor: AMD Radeon RX 5700 > ``` ADDITIONAL INFORMATION ---------------------- Not all were able to be reported: > Package | Report | Traces > ---------------------------|--------------------------------------------------------|-------------------------------------------------------- > `plasma-workspace` | https://bugzilla.redhat.com/show_bug.cgi?id=2269942#c0 | `/var/spool/abrt/ccpp-2024-09-18-12:19:14.67601-8362` > `browser-integration` | | `/var/spool/abrt/ccpp-2024-09-18-12:19:52.774372-10607` > `browser-integration-host` | | `/var/spool/abrt/ccpp-2024-09-18-12:19:53.44110-10912` I'll try to attach those `ccpp` reports. To correlate those reports to boots, `journalctl --list-boots`' output is undermentioned: > ```log > Index BootID FirstEntry LastEntry > ----- ------ ---------- --------- > -2 31bcd8e103064c6aa5269026a0b691c5 18/09/2024 12:16:12 18/09/2024 12:28:48 > -1 01fe61d209b24be7bec51108ed9b06f1 18/09/2024 12:37:46 18/09/2024 12:41:05 > 0 b0fe282b8df4441c97b6089019cde3fe 18/09/2024 13:27:21 18/09/2024 14:27:37 > ```
(In reply to Roke Julian Lockhart Beedell from comment #0) Uploading the reports as archives might take a moment - https://bugs.kde.org/show_bug.cgi?id=492371#c0 is making it really difficult for me, per https://bugzilla.redhat.com/show_bug.cgi?id=2279566#c15.
Created attachment 173829 [details] ccpp-2024-09-18-12:19:52.774372-10607.7z
Created attachment 173830 [details] ccpp-2024-09-18-12:19:53.44110-10912.7z
I can't upload the last attachment, because even when put through `7z` with LZMA2, it's still 4,244,946 KiB. I've uploaded it to https://drive.google.com/file/d/1ZPu4e5Avd4CkiKoeHWNsPIJX89Pz_c6f/view?usp=drive_link instead.
When something crashes, all we need is a backtrace of the crashing thread. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl *** This bug has been marked as a duplicate of bug 488653 ***
(In reply to Nate Graham from comment #5) Apologies. Don't know why I forgot that. I'll re-read the docs. Thanks for triaging it.
(In reply to Nate Graham from comment #5) Though, considering that plasma-desktop crashed, and the entire OS hung, is this really a direct duplicate? Perhaps I've just filed it badly?
Lots of crashes can OOM the system and cause other things to crash or exit, yeah. That's Bug 489315.
(In reply to Nate Graham from comment #8) Thanks lots for that - being OOM hanging the OS might help to diagnose that AMD https://gitlab.freedesktop.org/drm/amd/-/issues/3462#note_2573860 too. I always thought the OS would just use the pagefile if it used all of its available SDRAM.
It does, but that can get filled up too, as it's typically not configured to be unbounded in size.