touch-packages team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

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