SUMMARY The Falkon KDE Frameworks Integration extension is linked to KCrash and attempts to initialize it, but crashes are not actually intercepted by it. STEPS TO REPRODUCE 1. Start Falkon. 2. Simulate a crash: killall -SIGABRT falkon OBSERVED RESULT Falkon exits without spawning DrKonqi, but KCrash is configured to do just that on this system. EXPECTED RESULT DrKonqi comes up with the crash intercepted by KCrash. SOFTWARE/OS VERSIONS Fedora 28 with updates Falkon 3.1.0 KDE Plasma 5.13.5 KDE Frameworks 5.55.0 QtWebEngine 5.12.2 Qt (QtBase etc.) 5.11.3
Works here, latest ArchLinux. Does it work for other KDE apps for you? Also please note that now drkonqi just shows notifications and is not opened until you click on the icon in tray.
Hmmm, this is interesting… If I try this with KWrite, I get the DrKonqi tray icon if KWrite was run from Konsole, but not if it was run from the menu. (Huh?) With Falkon, I never get the DrKonqi tray icon no matter how Falkon was run, even if I run it from the same Konsole from which I started KWrite when KCrash worked.
Actually here it works even without calling KCrash::init(), just loading the libKF5Crash library is enough. It happens when loading all available plugins when opening Preferences.
You need something like this: https://cgit.kde.org/kdevelop.git/commit/?id=ef0af08a9d4889ec5295a788900d1f38af67bb8a I can confirm that running: falkon & killall -SIGABRT falkon in a Konsole gives me a backtrace from Chromium to the Konsole, whereas running: QTWEBENGINE_CHROMIUM_FLAGS=--disable-in-process-stack-traces falkon & killall -SIGABRT falkon gives me DrKonqi as expected.
Reassigning back to Falkon as there is clearly a Falkon bug here. Though there may be a KCrash bug too (see comment #2), I may have to file a second bug.
I also finally managed to track down the issue from comment #2. It appears to be due to the plasmashell respawning on crash, see bug #410785. So let us please focus on Falkon in this bug, see comment #4.
Ping? Can we get something like this: https://cgit.kde.org/kdevelop.git/commit/?id=ef0af08a9d4889ec5295a788900d1f38af67bb8a added to Falkon so that KCrash integration actually works?
Ping?
My vote goes for this, due to actually crashes reported inside (alternative) downstream abrt itself.
I've tested with Falkon 3.1.0 using your examples. Run falkon from konsole and from menu. When calling killall -SIGABRT falkon both times I was presented with the DrKonqi tray icon and a notification. Can you please re-test and confirm.
Operating System: Solus 4.1 KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.14.2
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Kevin, what's the actual state for this issue in downstream Fedora?
Unfortunately, I'm still running outdated Fedora versions at this time. Can you or some other Fedora user test this? I somehow cannot believe that this is magically fixed, considering that nothing was done to fix it (as far as I can tell, also not in Qt upstream nor in Chromium).
This appears to be a downstream issue with Fedora. I just tested with a live Fedora 33 KDE ISO and it won't bring up DrKonqi when I SIGABRT falkon but it does when I do it to konsole. I'd suggest raising with the Fedora team.
This is absurd. I have pointed out very clearly at what needs to be fixed in this upstream code. See also: https://www.dvratil.cz/2018/10/drkonqi-and-qtwebengine/ . This is clearly an upstream issue. I have no idea why your distro is not affected. It might be setting QTWEBENGINE_CHROMIUM_FLAGS=--disable-in-process-stack-traces systemwide or have some other downstream workaround.