My guess is that with KDE Frameworks 5.52, KCrash's behaviour was changed so that it was injected into ALL Qt applications under a KDE session, rather than just KDE specific ones.
With the KDE crash handler present, RPCS3 crashes very early on when booting most games, whereas with it absent, everything works perfectly fine.
The crash produces output similar to this
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = rpcs3 path = /usr/bin pid = 50951
KCrash: Arguments: /usr/bin/rpcs3
KCrash: Attempting to start /usr/lib/drkonqi from kdeinit
pa_write() failed while trying to wake up the mainloop: Bad file descriptor
Invalid write to eventfd: Bad file descriptor
Code should not be reached at pulsecore/fdsem.c:199, function pa_fdsem_post(). Aborting.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
1. run RPCS3
2. boot a game
3. it crashes
1. run RPCS3 with KDE_DEBUG=1
2. boot a game
3. it runs perfectly
presence of KCrash shouldn't affect the runtime behaviour of RPCS3.
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.52.0
Qt Version: 5.11.2
GCC Version: 8.2.1
RPCS3 issue: https://github.com/RPCS3/rpcs3/issues/5324
Additionally, the official AppImages provided by RPCS3 does not exhibit the issue - my guess is largely because it bundles its own older Qt
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.
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);
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
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
This patch is effectively a copy of
02b523bad09aab062355e46771889b0f3709692f in kxmlgui for enabling auto-
accelerators only if the lib is linked directly.
Changed the crashtest app in drkonqi to not directly link - didn't get drkonqi
Re-enabled linking. Got drkonqi
Differential Revision: https://phabricator.kde.org/D23171
M +33 -0 src/kcrash.cpp