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 Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1278780 Title: apport takes too long to write crash report, appears to lock up phone Status in Apport: Confirmed Status in Canonical System Image: Confirmed Status in qtubuntu: Invalid Status in apport package in Ubuntu: Triaged Status in qtmir package in Ubuntu: Confirmed Bug description: I can trigger a crash easily on my phone via bug 1262711. Other bugs are available. When that happens my phone appears to freeze. I am unable to do anything for approximately 1 to 1.5 minutes. As a user my initial gut reaction is to reboot the phone, thus losing the crash report, and wasting my time. Having the phone lock up for 1.5 minutes is a terrible user experience. Can we fix/mitigate/workaround that? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: apport 2.13.2-0ubuntu2 Uname: Linux 3.4.0-3-mako armv7l ApportVersion: 2.13.2-0ubuntu2 Architecture: armhf CrashReports: 664:32011:110:10083:2014-02-10 15:41:18.152893384 +0000:2014-02-10 15:11:09.169231740 +0000:/var/crash/_usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash 640:0:110:1681527:2014-02-10 15:12:10.985193887 +0000:2014-02-10 15:12:05.639489630 +0000:/var/crash/_usr_bin_powerd.0.crash 640:0:110:21384:2014-02-11 07:58:44.876281991 +0000:2014-02-11 07:58:44.876281991 +0000:/var/crash/_usr_sbin_system-image-dbus.0.crash 640:32011:110:17122318:2014-02-11 09:19:49.915478726 +0000:2014-02-11 09:18:20.850439824 +0000:/var/crash/_usr_bin_unity8.32011.crash Date: Tue Feb 11 09:20:15 2014 InstallationDate: Installed on 2014-02-11 (0 days ago) InstallationMedia: Ubuntu Trusty Tahr (development branch) - armhf (20140211) PackageArchitecture: all ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR=<set> SHELL=/bin/bash SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1278780/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
