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
...
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.
Turns out to be a real bug in the X86 asm backend:
http://llvm.org/bugs/show_bug.cgi?id=20800
The compact unwind info for this function contains the wrong stack frame size.