en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/test/asan/TestCases/Darwin/symbolizer-function-offset-dladdr.cpp#923cf890 Avoid failing a CHECK in `DlAddrSymbolizer::SymbolizePC`.Summary: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 reportingan issue is very unhelpful. Instead we now try to compute a function offsetif the value we get back from `dladdr()` looks sane, otherwise we don'tset the function offset.A test case is included. It's basically a slightly modified version ofthe 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 0x2195c870libdyld.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 pointsinto the middle of a instruction.There might also be other bugs lurking here because I noticed that the PCs wegather during stackunwinding (before changing them with`StackTrace::GetPreviousInstructionPc()`) look a little suspicious (e.g. thePC stored for the frame with fail to symbolicate is 0x2195c873) as they don'tlook properly aligned. This probably warrants further investigation in the future.rdar://problem/65621511Reviewers: kubamracek, ylnSubscribers: kristof.beyls, llvm-commits, #sanitizersTags: #sanitizersDifferential Revision: https://reviews.llvm.org/D84262 List of files: /llvm-project-15.0.7/compiler-rt/test/asan/TestCases/Darwin/symbolizer-function-offset-dladdr.cpp Tue, 21 Jul 2020 18:54:51 +0000 Dan Liew <dan@su-root.co.uk>