Comment 19 for bug 1278780

On Thu, Oct 22, 2015 at 03:27:59PM -0000, Thomas Voß wrote:
> So a few thoughts:

> * Releasing graphics buffers in case of SIGSEGV seems to be quite
> dangerous as we are dealing with potentially corrupted memory. I
> don't think we should take this approach.

Why is this "quite dangerous"? Releasing the buffers should be a simple
matter of munmap(), shouldn't it? (We shouldn't do any kind of complex
"cleanup" of the buffers in the SIGSEGV handler, just drop them completely
from the process's memory.) If the references to the graphics buffers have
themselves been corrupted, then you can wind up unmapping the wrong area of
memory; but that is an unlikely scenario, and the worst case outcome is that
it causes a second segfault, which we can be sure to handle correctly (by
not handling it).

> * It would be nice to have the ability to skip core dumping and instead
> just produce a threaded stack trace (probably in a gray list
> maintained by apport). This obviously takes away some information,
> but it's probably a good tradeoff for the time being.

That is fundamentally not possible without running the process under a
tracer (such as gdb). If you are using the kernel crash handler, the only
way to get this stack trace is by first reading the core from the kernel fd,
because this fd isn't going to be seekable.

> * If we really want to dump, we could investigate into sendfile. I'm not
> * entirely sure that it works with data coming in via stdin, but it's
> * worth a try as we would avoid the kernel -> userspace copy.

This is an interesting suggestion. It would imply requiring a second
post-processing stage, to combine this file with the rest of the crash
report in proper (compressed, base64-encoded) format; but that
post-processing is certainly something that could be done outside of the
kernel handler, letting the crashed process exit sooner.

IMHO this is worth investigating, but should be done in parallel with the
munmap() handling. Writing large uncompressed crash files to disk, even
with sendfile, is going to be unpleasant, and we still want to minimize the
amount of irrelevant information they contain.