kio slaves + kcrash + drkonqi

[Harald Sitter]

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