Hey I am a bit confused about crash handling in kio slaves. As in: it's not working the way it should be working and I don't know why it is the way it is.
The debugging faq [1] suggest that this should behave like KCrash. by default all crashes get drkonqi'd unless you set KDE_DEBUG at which point drkonqi is disabled. However, having quickly jumped through the kdelibs history I am not sure that was true even before the kf5 shake up... kio/src/core/slavebase.cpp has ``` if (qEnvironmentVariableIsEmpty("KDE_DEBUG")) { ::signal(SIGSEGV, &sigsegv_handler); .... ``` sigsegv_handler is a local crash handler that is bypassing kcrash AND drkonqi entirely and instead prints a backtrace() to stderr. i.e. by default a slave crash is logged via the local-to-slave crash handler to stderr. when setting KDE_DEBUG even that logging gets disabled. Now to me that makes no sense at all. Why would one want to disable a simple backtrace print? More importantly, why would one bypass kcrash at all? You might rightfully ask why I even care though. The problems are: a) kcrash isn't used or initialized -> no drkonqi -> no user visible crash reports about bugged out slaves (as a result it's near useless to have any q_asserts or qfatals whatsoever in slaves) and we wouldn't know if the slave quality is garbage b) since kcrash isn't used -> no recording in dump handler applications like coredumpd/apport/ABRT -> no way to retrace/report after the fact either for sysadmins or distros c) even if kcrash was used it'd still be overridden by the local-to-slave handler, meaning a slave author can't even force kcrash use unless they know about this and know how to force the correct handler to be installed after the local-to-slave handler. To me it seems all of this is weird and horrible and what I think would make much more sense is: - SlaveBase drops the KDE_DEBUG check - SlaveBase calls KCrash::initialize() - SlaveBase uses KCrash::setCrashHandler to set its own crash handler to print the backtrace on stderr - SlaveBase's backtrace handler then forwards to KCrash::defaultCrashHandler so shared logic runs (i.e. drkonqi and then forwarding to dump handlers on linux) - Possibly KCRASH_AUTO_RESTARTED needs setting by something in KIO. >From what I see, if I make a slave crash on every invocation, KIO would try to repeat the action it wanted to do by restarting the salve ad infinitum when instead it should abort at some point so as to not spam the user with drkonqis. The end result is that we still have the stderr backtrace, which I think is very useful. In fact, by dropping the KDE_DEBUG condition it's always enabled even when the user disables drkonqi using KDE_DEBUG=1. The user will get a GUI in the form of drkonqi enabling them to file a crash report with us so we actually know that our slaves are crashing. Through KCrash the crash is also forwarded to system level crash handlers, if applicable, so sysadmins or distros also know that our slaves are crashing. (In fact, I'd even argue that maybe kcrash itself should do the backtrace() print. It seems useful in all crash scenarios I'd imagine, in particular consider drkonqi can be disabled or not installed. But then I don't know if/what performance penalty it'd entail with regards to auto restarts.) Thoughts? [1] https://community.kde.org/KDE/FAQs/Debugging_FAQ