Apport abort() handler in glibc

Registered by Kees Cook on 2009-04-28

Due to the increasing use of abort() in various failure modes (Xorg, FORTIFY asserts, etc), there needs to be a generalized way to catch the glibc assert backtrace and core file that is produced in these situations. Currently apport ignores SIGABRT, but it would be much better to catch them in a useful way.

Blueprint information

Status:
Complete
Approver:
Rick Clark
Priority:
Undefined
Drafter:
Kees Cook
Direction:
Needs approval
Assignee:
Martin Pitt
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Kees Cook on 2009-05-20
Completed by
Martin Pitt on 2009-09-15

Related branches

Sprints

Whiteboard

given Upstart's massive use of assertions and abort(), and that when it dies your entire system goes with it, I'd like to figlet ++ here ;)

First version will be adding a global symbol that is set to the assert string before dumping core, which apport can extract when analyzing the core dump.

- apport keep core fd open until the end for avoiding kernel failure
- init crashes via child
- global ptr in glibc assert
- take all aborts, throw away once processed if not assert/whitelist

pitti, 2009-08-26: Committed to trunk:

  Do not generally ignore SIGABRT any more. Try to extract the assertion
  message from the core dump, and add it as "AssertionMessage" field. Mark
  reports as unreportable if they do not have an assertion message and crashed
  with SIGABRT. This requires your glibc to have this patch:
  http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=48dcd0ba

  However, I'm unclear about the "apport keep core fd open until the end for avoiding kernel failure" bit. How can thisi be tested? What needs to be changed? Can you please clarify this in the wiki spec?

 Oh, and right now I'm using gdb and "print (char*) __assert_msg" for this, which means I can only determine this in post-processing. Is there a way to determine whether the core dump has an assert msg just by looking at the core dump itself when getting it piped in? Then we wouldn't need to bother the user about unreportable crash reports, and they could be discarded right away.

SIGABRT handling uploaded to Karmic in 1.8.

kees, 2009-08-26:
 - the "keep core fd open" was a supposition by Keybuk that the kernel would panic after the coredump fd for init closed. One of the goal for abort-catching was to be able to get meaningful crashes out of upstart, which may require some special handling depending on how the kernel does the dumping.
 - as I understand it, extracting the __assert_msg during pre-processing requires reading the coredump, processing the headers and sections, parsing the symbol table, resolving "__assert_msg" to a core location and reading out the value. (i.e. full ELF parsing would be needed, which is possible, but not immediately available to python).

pitti, 2009-09-15: glib now also stores assertion messages into __abort_msg. Is there anything else what's left here? Setting to implemented now.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.