When the report points to a program, not a shared library
Run addr2line -e myapp 080513b
(and repeat for the other instruction pointer values given) to see where the error is happening. Better, get a debug-instrumented build, and reproduce the problem under a debugger such as gdb.
If it’s a shared library
In the libfoo.so[NNNNNN+YYYY]
part, the NNNNNN
is where the library was loaded. Subtract this from the instruction pointer (ip
) and you’ll get the offset into the .so
of the offending instruction. Then you can use objdump -DCgl libfoo.so
and search for the instruction at that offset. You should easily be able to figure out which function it is from the asm labels. If the .so
doesn’t have optimizations you can also try using addr2line -e libfoo.so <offset>
.
What the error means
Here’s the breakdown of the fields:
address
– the location in memory the code is trying to access (it’s likely that10
and11
are offsets from a pointer we expect to be set to a valid value but which is instead pointing to0
)ip
– instruction pointer, ie. where the code which is trying to do this livessp
– stack pointererror
– Architecture-specific flags; seearch/*/mm/fault.c
for your platform.