llvm dev - Aug 2014 - [LLVMdev] Verifying unwind info/debugging a crash in _Unwind_Backtrace() on OSX

Hi all,

I'm debugging a crash in the guts of libunwind that started occuring
when I changed the ASan runtime to use _Unwind_Backtrace() on OSX to
report errors.
The crash happens for every test case that has an ASan report in it,
so I'm suspecting something's wrong with the unwind info generated by
the Xcode Clang, which I'm using to build my Clang and the ASan
runtime library (with either -funwind-tables or
-fasynchronous-unwind-tables).
GDB is also unable to unwind past a certain frame in the runtime library.

$ gdb ./p
...
==================================================================23138==ERROR:
AddressSanitizer: stack-buffer-overflow on address
0x7fff5fbffad5 at pc 0x000100000e25 bp 0x7fff5fbffa30 sp
0x7fff5fbffa28
WRITE of size 1 at 0x7fff5fbffad5 thread T0
==26613==got pc: 0x00010004a17c
==26613==got pc: 0x00010003b199
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff8d734a81 in
libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless
()
(gdb) bt
#0  0x00007fff8d734a81 in
libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingFrameless
()
#1  0x00007fff8d73233b in
libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncoding
()
#2  0x00007fff8d7322e1 in
libunwind::UnwindCursor<libunwind::LocalAddressSpace,
libunwind::Registers_x86_64>::step ()
#3  0x00007fff8d736262 in _Unwind_Backtrace ()
#4  0x000000010004a17c in SlowUnwindStack () at
/Users/glider/src/asan2/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind.cc:116

I've inserted a debug printf into the callback passed to
_Unwind_Backtrace (note the "got pc" lines above) and can see that
_Unwind_Backtrace correctly finds the address of the function that
calls SlowUnwindStack (it's named __asan_report_error), but then
crashes.

Is there a way to check whether the unwind info is correct? Could this
be a bug in the system implementation of _Unwind_Backtrace, which
probably should not crash in the middle of a valid stack trace?

Thanks in advance for any pointers,
Alexander Potapenko

PS. LMK if this is an offtopic for LLVMdev.

> Is there a way to check whether the unwind info is correct? Could this
 > be a bug in the system implementation of _Unwind_Backtrace, which
 > probably should not crash in the middle of a valid stack trace?

I'm not experienced with OSX but AFAIK unwinders generally trust unwind 
bytecode so if the latter is broken and causes SP miscalculation, 
unwinder will happily read invalid memory and segfault.

You may want to examine unwind tables for Asan runtime (via readelf -u) 
and compare those to e.g. assembler code of __asan_report_error.

-Y

Turns out OSX uses a different format of unwind info, the so-called
compact unwind encoding.
Some of its contents can be obtained from a thin (non-universal)
binary by `llvm-objdump -unwind-info`
Right now I'm trying to make Clang use the _Unwind_Backtrace
implementation from libc++abi instead of the system one so that it's
possible to debug it.

On Wed, Aug 27, 2014 at 6:48 PM, Yury Gribov <y.gribov at samsung.com>
wrote:
>> Is there a way to check whether the unwind info is correct? Could this
>> be a bug in the system implementation of _Unwind_Backtrace, which
>> probably should not crash in the middle of a valid stack trace?
>
> I'm not experienced with OSX but AFAIK unwinders generally trust unwind
> bytecode so if the latter is broken and causes SP miscalculation, unwinder
> will happily read invalid memory and segfault.
>
> You may want to examine unwind tables for Asan runtime (via readelf -u) and
> compare those to e.g. assembler code of __asan_report_error.
>
> -Y


-- 
Alexander Potapenko
Software Engineer
Google Moscow