| Summary: | KDE crash handler conflicts with RPCS3 | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kcrash | Reporter: | Hirato <billy65bob> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugs.kde.org.facelift226, joh82875, john.ettedgui, kdelibs-bugs, zionnimchuk |
| Priority: | NOR | ||
| Version: | 5.52.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kcrash/e64b8314e201e255dbb338aa41317362b545d47a | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Hirato
2018-12-02 03:13:14 UTC
We cannot disable the crash handler, but if you know how to make it work with RPCS3, please add a comment. The referenced issue only says "RPCS3 is doing some weird stuff to facilitate PS3 exception handling", which does not give us a hint. Thing is we didn't used to have to run it with KDE_DEBUG set. And therein lies the main complaint in this bug report. IMO the simplest and probably ideal fix would be to ensure that KCrash only autoloads for KDE applications, and not generic Qt ones (unless explicitly requested). I mean, backtraces for third party programs like RPCS3 or QtCreator just don't belong here - so I don't think there's value in installing KCrash' crash handlers into them. You could disable Qt's KDE integration plugin, just do not set XDG_CURRENT_DESKTOP=kde, but use something else, e.g. XDG_CURRENT_DESKTOP=qt. That does look like a second workaround... It kind of looks like RPCS3 by design generates a lot of SIGSEGVs. I had a look at the code - I probably don't understand it properly, but it seems that RPCS3 engages its own signal handler at startup, as seen here. https://github.com/RPCS3/rpcs3/blob/master/Utilities/Thread.cpp#L1562-L1576 1568 if (::sigaction(SIGSEGV, &sa, NULL) == -1) If I understand you correctly, KCrash then comes along via a KDE QPA (would this be KDEPlasmaPlatformTheme or KWinQpaPlugin? both list KCrash via ldd). According to KCrash.cpp - it sets up its signal handler via QApplication's initialisation, I presume the Q_COREAPP_STARTUP_FUNCTION(kcrashInitialize) is responsible for this. Then RPCS3's handler is replaced here: 331 #ifdef SIGSEGV 332 signal(SIGSEGV, handler); 333 sigaddset(&mask, SIGSEGV); 334 #endif Since RPCS3 does not make use of KF5, I think it's unreasonable to expect them to change XDG_CURRENT_DESKTOP, export KDE_DEBUG, or including KCrash solely to invoke KCrash::setDrKonqiEnabled(false); Git commit e64b8314e201e255dbb338aa41317362b545d47a by David Edmundson. Committed on 15/08/2019 at 09:25. Pushed by davidedmundson into branch 'master'. Avoid enabling kcrash if it's only included via a plugin Summary: If a Qt app happens to load our plasma-integration plugin it shouldn't change how bug reporting works. There's no point showing drkonqi if there's not an appropriate KDE product. Worse, our crash handling can interfere with that processes own signal handling. This patch is effectively a copy of 02b523bad09aab062355e46771889b0f3709692f in kxmlgui for enabling auto- accelerators only if the lib is linked directly. Test Plan: Changed the crashtest app in drkonqi to not directly link - didn't get drkonqi Re-enabled linking. Got drkonqi Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D23171 M +33 -0 src/kcrash.cpp https://commits.kde.org/kcrash/e64b8314e201e255dbb338aa41317362b545d47a |