KCrash crash racing

[Harald Sitter]

Moin Moin!

I've been haunting down a nasty backtrace problem in drkonqi where it
entirely fails to create a backtrace and am now fairly confident this
is in fact a design flaw with kcrash, but I have no awesome ideas on
how to solve this properly.

Long story short: there is a space of time between SEGV occurring and
drkonqi stopping the threads. This causes (e.g.) GIO threads to
actively unavoidably crash the process. Most recently this could/can
be observed with plasmashell which has a GIO thread sitting around
when (I think) flatpak updates are being checked. The result is that
the crash cannot be traced because the process dies before drkonqi has
a chance to deal with it.

If you have ever seen a warning or error of the kind "XCB connection
lost" or something similar it is in fact the very same problem, albeit
usually not fatal.

When a process crashes SEGV is sent to any one thread. The other
threads continue to run!
When the SEGV arrives the standard handler will possibly restart the
process, then close all open file descriptors, potentially start (and
wait for) drkonqi and when drkonqi has worked its magic raise itself
to a core pattern process if applicable [1].
The threads have still not been suspended!
When drkonqi starts, it sends STOP to the crashed process. STOP is
delivered to every thread, thus stopping everything this time around.
Only now is the process "safe" from crashing while crashing.

And that's the race right there. In between the file descriptors
getting closed and the STOPping the threads that aren't being handled
and continue to run to potentially access the now-closed file
descriptors. In GIO's case it can try to read inotify events and run
into an error (e.g. in ik_source_read_some_events) and g_error, which
as far as I can tell will result in a TRAP because g_error almost
always(?) ends in g_abort.

The solution is simply: we shouldn't close FDs before all threads are stopped.

Practically I can't think of a way to actually pull this off though.
We'd need to close the FDs *at* STOP. But STOP like KILL cannot be
handled.

I think the actual solution here would need to be that kcrash stops
invoking drkonqi and instead defers to a core handler through which
drkonqi can get access to the core.
Trouble is that there can only be one core handler and there are more
software providers on a system than just us, so I guess this isn't
really a viable solution :/
Also the core stuff isn't too portable I think.

I am fairly out of ideas :/

[1] http://man7.org/linux/man-pages/man5/core.5.html