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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1278780 Title: apport takes too long to write crash report, appears to lock up phone To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1278780/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
