Bug 439279

Summary: Automatically closed while crash report in process
Product: [Applications] drkonqi Reporter: Wyatt Childers <kdebugs.81do7>
Component: generalAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED DOWNSTREAM    
Severity: normal CC: sitter
Priority: NOR    
Version First Reported In: 5.22.2   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Wyatt Childers 2021-06-28 21:16:49 UTC 
SUMMARY
While attempting to report Bug 439278 via the crash reporter, the crash reporter was closed by whatever was managing the plasmashell auto recovery.

STEPS TO REPRODUCE
1. Crash plasmashell via lockup
2. Start to file a report
3. Wait for plasmashell to respawn

OBSERVED RESULT
drkonqi is closed/crashes/otherwise disappers

EXPECTED RESULT
drkonqi allows the report to be finished

SOFTWARE/OS VERSIONS
Operating System: Fedora 34
KDE Plasma Version: 5.22.2
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2
Kernel Version: 5.12.12-300.fc34.x86_64 (64-bit)
Graphics Platform: X11
Processors: 32 × AMD Ryzen 9 3950X 16-Core Processor
Memory: 62.8 GiB of RAM
Graphics Processor: AMD NAVY_FLOUNDER

ADDITIONAL INFORMATION
Comment 1 Harald Sitter 2021-07-02 10:22:32 UTC 
From your description and the fact that you are on fedora I'm guessing that this happened because fedora uses experimental systemd service startup to manage the session. The caveat there is that the drkonqi process is part of the unit that crashed, which then means that if systemd decides to restart the unit (which it will when crashed) it will forcefully terminate drkonqi because it cleans up the previous processes spawned by the unit.

For 5.22 there's nothing we can do about that. In 5.23 there's a new coredumpd based post-mortem system where drkonqi doesn't actually directly relate to the process that crashed, but the process terminates, its memory gets recorded by systemd's coredumpd and then we start drkonqi from there to debug the dumped process rather than the live process (that eventually gets killed by systemd).

The thing is, as far as I am aware fedora is using ABRT instead of coredumpd to handle these crashes, so practically speaking fedora probably shouldn't be shipping/enabling drkonqi at all but use ABRT. Certainly not in 5.22 because of the described problem. The latest kcrash sports an environment option KCRASH_DUMP_ONLY=1 for that. When set drkonqi is not started by the crashing application but the app will dump its core, invoking the global core handler (supposedly ABRT) and everything else happens there. You may want to bring this to fedora's attention.