Generate core dumps for packaged programs as well

For packaged programs, feisty's apport does not *ever* save core dumps, because /proc/sys/kernel/core_pattern now points to a pipe instead of a file.

Apport does generate core files for unpackaged programs if ulimits permit. I'll move the check for SIGABRT down after the core file creation, so that SIGABRT will generate cores for those programs.

Apologies for not distinguishing between cores and crash reports with embedded cores.

Let me step back. If a process dies with SIGABRT, I'm looking for either (1) the core file in a well-known location or (2) apport invoking a package-hook and we can get at the core through that. As I understand, your patch enables (1); to get (2), we need both this patch and to install via a package that provides a package-hook. Will your patch also allow SIGABRT-generated reports to reach (2)? (VMware is at (1) now, but would like to reach (2)).

From apport sources, it looks like (1) would be CWD/core or CWD/core.PID (depending on the core_uses_pid setting).

 apport (0.67) feisty; urgency=low
 .
   * debian/local/setup-apport-retracer: Add apt sources for restricted,
     universe, and multiverse, too.
   * po/de.po: Update from Rosetta.
   * apport/report.py: Remove undefined call to error_log() in
     _command_output(), replace it with raising proper exceptions.
   * bin/apport-retrace: Fix 'numer' typo. (LP: #91680)
   * test-apport: Check that non-packaged executables generate a core dump on
     SIGABRT, too (test case for bug #92029).
   * bin/apport: Move check for ignoring SIGABRT below the core dump file
     writing for non-packaged binaries. (LP: #92029)
   * gtk/apport-gtk.glade:
     - Remove titles from the progress windows to comply with Gnome HIG and not
       repeat the text content.
     - Improve wording a bit.
     - LP: #92114
   * gtk/apport-gtk{,.glade}: Fix signal handler name of the Cancel button in
     the upload progress dialog, so that it actually works. (LP: #92115)

Thanks for fixing the initial drop.

I see the 0.67 sources. Sufficient for non-packaged installation. But, when shipped as a packaged .deb, a SIGABRT core will be dropped unconditionally, without having a chance to reach any error-reporting tool. (Oddly enough, this is an incentive to NOT package...).

Is there a reason to drop SIGABRT reports even from packaged installations? Should such a reason be package-specific? (Or is more work in progress? :-) )

> Will your patch also allow SIGABRT-generated reports to reach (2)?

Not according to my initial intentions, due to the principle of /proc/sys/kernel/core_pattern. (Also, VMWare works fine for me without throwing core dumps around, FWIW).

However, thinking about it again apport *could* write core dumps for packaged programs as well if ulimits permit. Since we default to ulimit -c 0, this would not change the default behaviour, and it would make the behaviour more consistent as well.

> Is there a reason to drop SIGABRT reports even from packaged installations? Should such a reason be package-specific? (Or is more work in progress? :-) )

The primary reason is that SIGABRT is mainly used on assertion failures in C and Mono. Since we currently do not have a possibility to get the assertion message, crash reports are useless. Our Gnome and Mono maintainers thus asked me to ignore ABRT in apport. There are, however, ideas how to get assertion messages, and there is a spec for Mono (https://wiki.ubuntu.com/ApportMonoCrashes).

Reopening for this idea.

Allowing cores for packaged programs if ulimit permits is sufficient for our needs.

We actually adjust ulimit early in the process because we want customers to optionally submit cores for debugging. (Glad to hear VMware software doesn't dump core for you ;-) - I wish our betas were that robust!).

>The primary reason is that SIGABRT is mainly used on assertion failures in C and Mono.

Sounds like a package-specific suppression override later in the process - like 87430. Fine that they don't want cores - but it becomes problematic if that blocks our cores.

Thanks for the Mono link - I'm learning interesting new ways to hook apport!

And many thanks for the quick communication!

 apport (0.69) feisty; urgency=low
 .
   * apport-chroot: Add command 'installdeb' to conveniently install a bunch of
     .debs into a chroot.
   * apport-chroot: Fix 'login' and 'upgrade' commands to not require
     specifying a chroot map when giving a chroot tarball path as argument.
   * test-apport: Check that core dumps are written for packaged programs as
     well, if ulimits want them. (Test for #92029)
   * bin/apport: Call write_user_coredump() for packaged program crashes and
     SIGABRT as well. (LP: #92029)