Created attachment 186416 [details] An Example Of A Konqi OOM # SUMMARY When Dr. Konqi initially appears, myriad bugs can prevent it being able initially report a bug, without at least a reinvocation: [^3] 1. Some cause it to fail to parse the trace. [^6] 2. Thereafter, in the past, graphical and UX bugs prevented certain pages being passed, [^5] or prevented the user being able to fix past inputs [^4] (which matters, because KDE BZ doesn't permit `#c0` to be modified). 3. Some continue to prevent reports, like OOMs, if the user neglects to close all other applications when Dr. Konqi appears. Considering that the user cannot choose when to report a crash with Konqi, this bug is the most prominent problem for me, and why I reported this. [^2] # STEPS TO REPRODUCE 1. Be debugging a game, like 0AD, or running a short, insignificant render in Blender. 2. Crash something huge, like Plasma Shell, in the background. An example is the automatic theme switching that causes https://bugs.kde.org/show_bug.cgi?id=506642#c21. # OBSERVED RESULT My FW16, with 32 GiB of (DDR5) SDRAM, frequently OOMs in these circumstances. # EXPECTED RESULT Like I can with `gnome-abrt-1.4.3-8.fc43` and `abrt-cli-2.17.7-1.fc43`, I expect to be able to invoke the crash report wizard via `drkonqi-coredump-gui` when I want to, so that I can wait until I've finished with those tasks. As it is, I've still lost those reports due to the OOM, but have also wasted time. I end-up just reporting most crashes downstream, to RedHat, due to this: 1. https://bugzilla.redhat.com/show_bug.cgi?id=2411864#c0 2. https://bugzilla.redhat.com/show_bug.cgi?id=2411868#c0 # SOFTWARE/OS VERSIONS > ~~~ > Name : plasma-drkonqi > Version : 6.5.1 > Release : 1.fc43 > Architecture: x86_64 > Install Date: Sat 01 Nov 2025 18:30:12 GMT > Size : 3598509 > Signature : RSA/SHA256, Thu 30 Oct 2025 18:55:45 GMT, Key ID 829b606631645531 > Source RPM : plasma-drkonqi-6.5.1-1.fc43.src.rpm > Build Date : Thu 30 Oct 2025 10:44:47 GMT > Build Host : buildhw-x86-09.rdu3.fedoraproject.org > Packager : Fedora Project > Vendor : Fedora Project > Bug URL : https://bugz.fedoraproject.org/plasma-drkonqi > ~~~ # ADDITIONAL INFORMATION [^1]: https://discuss.kde.org/t/how-to-edit-my-comments-in-bugs-kde-org/38510/8?u=rokejulianlockhart [^2]: https://discuss.kde.org/t/can-dr-konqi-be-reinvoked-after-closure/34410?u=rokejulianlockhart [^3]: https://bugs.kde.org/show_bug.cgi?id=505075 [^4]: https://bugs.kde.org/show_bug.cgi?id=456770 [^5]: https://bugs.kde.org/show_bug.cgi?id=456768 [^6]: https://bugs.kde.org/show_bug.cgi?id=454411
I am not the sole person to desire this, per https://askubuntu.com/a/1519339/1002900.
https://bugzilla.redhat.com/show_bug.cgi?id=2411919 is also a very pertinent, and ironic, example.
This would be useful when guiding a bug reporter through getting a backtrace and submitting it
Thank you!
Git commit a4b441573c9fe60e640c65c612c6ecf5678ebf74 by Harald Sitter. Committed on 06/11/2025 at 02:32. Pushed by sitter into branch 'master'. coredump-gui: implement reporting to KDE this turned out a bit invasive but is mostly straight forward. instead of manually tracking dependencies between members the Patient now has a FaultContext that gets initialized at the same time with the entire bundle of variables. for simplicity that includes some KDE specific stuff instead of complicating live with subclasses and casting and what not. a whole bunch of stuff in the cpp got renamed. m_faultContext initialization now uses the new drkonqi-core library to check if the crash was KDE software and then creates a suitable context. report() invokes drkonqi similar to drkonqi-coredump-launcher. error strings and return types have been adjusted accordingly. M +1 -0 src/coredump/gui/CMakeLists.txt M +74 -44 src/coredump/gui/Patient.cpp M +15 -9 src/coredump/gui/Patient.h M +1 -0 src/coredump/gui/qml/DetailsPage.qml https://invent.kde.org/plasma/drkonqi/-/commit/a4b441573c9fe60e640c65c612c6ecf5678ebf74