https://bugs.kde.org/show_bug.cgi?id=401637
--- Comment #4 from Hirato <billy65...@gmail.com> --- 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); -- You are receiving this mail because: You are watching all bug changes.
