It turns out the CHECK(addr >= reinterpret_cast<upt>(info.dli_saddr)
can fail because on armv7s on iOS 9.3 dladdr() returns
info.dli_saddr with an address larger than the address we provided.
We should avoid crashing here because crashing in the middle of reporting
an issue is very unhelpful. Instead we now try to compute a function offset
if the value we get back from dladdr() looks sane, otherwise we don't
set the function offset.
A test case is included. It's basically a slightly modified version of
the existing test/sanitizer_common/TestCases/Darwin/symbolizer-function-offset-dladdr.cpp
test case that doesn't run on iOS devices right now.
More details:
In the concrete scenario on armv7s addr is 0x2195c870 and the returned
info.dli_saddr is 0x2195c871.
This what LLDB says when disassembling the code.
(lldb) dis -a 0x2195c870 libdyld.dylib`<redacted>: 0x2195c870 <+0>: nop 0x2195c872 <+2>: blx 0x2195c91c ; symbol stub for: exit 0x2195c876 <+6>: trap
The value returned by dladdr() doesn't make sense because it points
into the middle of a instruction.
There might also be other bugs lurking here because I noticed that the PCs we
gather during stackunwinding (before changing them with
StackTrace::GetPreviousInstructionPc()) look a little suspicious (e.g. the
PC stored for the frame with fail to symbolicate is 0x2195c873) as they don't
look properly aligned. This probably warrants further investigation in the future.
rdar://problem/65621511