Bug 493321 - At boot, the browser integrator crashed so many times that it crashed Fedora twice.
Summary: At boot, the browser integrator crashed so many times that it crashed Fedora ...
Status: RESOLVED DUPLICATE of bug 488653
Alias: None
Product: plasma-browser-integration
Classification: Plasma
Component: Firefox (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: Kai Uwe Broulik
URL: https://drive.google.com/file/d/1ZPu4...
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-18 13:47 UTC by Roke Julian Lockhart Beedell
Modified: 2024-09-18 21:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screenshot of `gnome-abrt` displaying the 20+ crash logs. (186.55 KB, image/png)
2024-09-18 13:47 UTC, Roke Julian Lockhart Beedell
Details
ccpp-2024-09-18-12:19:52.774372-10607.7z (3.45 MB, application/x-7z-compressed)
2024-09-18 13:57 UTC, Roke Julian Lockhart Beedell
Details
ccpp-2024-09-18-12:19:53.44110-10912.7z (3.00 MB, application/x-7z-compressed)
2024-09-18 13:58 UTC, Roke Julian Lockhart Beedell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roke Julian Lockhart Beedell 2024-09-18 13:47:01 UTC
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
> ```
Comment 1 Roke Julian Lockhart Beedell 2024-09-18 13:54:23 UTC
(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.
Comment 2 Roke Julian Lockhart Beedell 2024-09-18 13:57:58 UTC
Created attachment 173829 [details]
ccpp-2024-09-18-12:19:52.774372-10607.7z
Comment 3 Roke Julian Lockhart Beedell 2024-09-18 13:58:14 UTC
Created attachment 173830 [details]
ccpp-2024-09-18-12:19:53.44110-10912.7z
Comment 4 Roke Julian Lockhart Beedell 2024-09-18 14:10:35 UTC
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.
Comment 5 Nate Graham 2024-09-18 17:09:28 UTC
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 ***
Comment 6 Roke Julian Lockhart Beedell 2024-09-18 18:13:52 UTC
(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.
Comment 7 Roke Julian Lockhart Beedell 2024-09-18 18:15:03 UTC
(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?
Comment 8 Nate Graham 2024-09-18 18:16:40 UTC
Lots of crashes can OOM the system and cause other things to crash or exit, yeah. That's Bug 489315.
Comment 9 Roke Julian Lockhart Beedell 2024-09-18 20:53:41 UTC
(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.
Comment 10 Nate Graham 2024-09-18 21:01:57 UTC
It does, but that can get filled up too, as it's typically not configured to be unbounded in size.