StacktraceAddressSignature is missing
Bug #1084996 reported by
Martin Pitt
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Apport |
Fix Released
|
High
|
Unassigned | ||
apport (Ubuntu) |
Fix Released
|
Undecided
|
Martin Pitt | ||
Precise |
Fix Released
|
Undecided
|
Unassigned | ||
Quantal |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Some crash reports are missing a StacktraceAddre
I seem to be able to reproduce this rather reliably with some simple X.org programs, such as
SRU TEST CASE:
$ (xeyes &); sleep 1; killall -SEGV xeyes
$ (xcalc &); sleep 1; killall -SEGV xcalc
With the current versions in precise and quantal, these reports usually do not have a StacktraceAddre
Changed in apport: | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in apport (Ubuntu): | |
assignee: | nobody → Martin Pitt (pitti) |
status: | New → Triaged |
Changed in apport (Ubuntu): | |
status: | Triaged → In Progress |
description: | updated |
Changed in apport (Ubuntu Precise): | |
status: | Fix Committed → In Progress |
tags: | removed: verification-needed |
To post a comment you must log in.
This happens for stack traces whose first 15 frames consist of more than 20% unresolvable addresses, i. e. addresses which do not belong into any known range in /proc/pid/maps. For example, an xeyes stack trace without debug symbols looks like this:
#0 0x00007fa41cf4b430 in __poll_nocancel () at ../sysdeps/ unix/syscall- template. S:81 x86_64- linux-gnu/ libXt.so. 6 x86_64- linux-gnu/ libXt.so. 6 x86_64- linux-gnu/ libXt.so. 6 0x7fff260180a8, init=<optimized out>, fini=<optimized out>, rtld_fini= <optimized out>, stack_end= 0x7fff26018098) at libc-start.c:227 00018, 4200756, 140733831020704, 0, 0, 701352281413172 3950, 705361780580400 2990}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x403030, 0x7fff260180a8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 4206640}}}
not_first_ call = <optimized out>
#1 0x00007fa41da94458 in _XtWaitForSomething () from /usr/lib/
#2 0x00007fa41da95df3 in XtAppProcessEvent () from /usr/lib/
#3 0x00007fa41da8a4bd in XtAppMainLoop () from /usr/lib/
#4 0x00000000004018e7 in ?? ()
#5 0x00007fa41ce81c15 in __libc_start_main (main=0x401760, argc=1, ubp_av=
result = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -70134352096802
#6 0x000000000040195d in ?? ()
#7 0x00007fff26018098 in ?? ()
#8 0x000000000000001c in ?? ()
#9 0x0000000000000001 in ?? ()
#10 0x00007fff26019776 in ?? ()
#11 0x0000000000000000 in ?? ()
Note the very low addresses in frames 8, 9, and 11. These are absolutely impossible as under Unix the first page (i. e. everything up to 0xFFF) is always unallocated memory. So these look like gdb artifacts. With x11-apps-dbgsym, these are gone and it looks much cleaner:
#0 0x00007fa41cf4b430 in __poll_nocancel () at ../sysdeps/ unix/syscall- template. S:81 x86_64- linux-gnu/ libXt.so. 6 x86_64- linux-gnu/ libXt.so. 6 x86_64- linux-gnu/ libXt.so. 6 xeyes.c: 137
#1 0x00007fa41da94458 in _XtWaitForSomething () from /usr/lib/
#2 0x00007fa41da95df3 in XtAppProcessEvent () from /usr/lib/
#3 0x00007fa41da8a4bd in XtAppMainLoop () from /usr/lib/
#4 0x00000000004018e7 in main (argc=1, argv=<optimized out>) at ../xeyes/
app_context = 0xd0b0e0
toplevel = <optimized out>
arg = {{name = 0x604792 <XtShellStrings+18> "iconPixmap", value = 67108865}, {name = 0x6047be <XtShellStrings+62> "iconMask", value = 67108867}}
i = 2
So as a first and very safe measure, we can ignore frames with addresses < 0x1000. Also, by now I have grown quite a lot of confidence in our StackAddressSig nature approach, so I'm inclined to remove the current safety heuristics of "at most 20% frames without resolvable offsets" and just ignore frames with unresolvable offsets instead. We still keep the minimum length requirement.