[llvm-bugs] [Bug 43339] New: ASan shows wrong crash locations

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43339

            Bug ID: 43339
           Summary: ASan shows wrong crash locations
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: asan
          Assignee: unassignedbugs at nondot.org
          Reporter: choller at mozilla.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 22514
  --> https://bugs.llvm.org/attachment.cgi?id=22514&action=edit
Testcase

The attached file shows that ASan is printing the wrong crash stacks for
certain crashes:

$ clang++ -O2 -g -fsanitize=address -o test.o test.cpp && ./test.o
If you see a crash in line 34, then ASan is printing the wrong stack.
Calling testCrashFoo...
AddressSanitizer:DEADLYSIGNAL
=================================================================
==28753==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc
0x0000004efe3c bp 0x7ffd0b6721e0 sp 0x7ffd0b672100 T0)
==28753==The signal is caused by a WRITE memory access.
==28753==Hint: address points to the zero page.
    #0 0x4efe3b in main test.cpp:34:5
    #1 0x7f91857c4b96 in __libc_start_main
/build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #2 0x41b399 in _start (test.o+0x41b399)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV test.cpp:34:5 in main
==28753==ABORTING


Note that ASan claims the crash to be in line 34 while it actually is in line
43. It might be possible to shrink the testcase further, I extracted this from
a live example in mozilla-central. We have had other cases where this happens,
where stacks are pointing to other crash locations, even non-forced ones (ASan
claiming a null-deref somewhere even though the crash is a MOZ_CRASH several
lines further).

I've tested this locally on Clang 7 and Clang Trunk
(3d0fbafd0bce43bb9106230a45d1130f7a40e5ec).

We have tried to analyze the problem further in
https://bugzilla.mozilla.org/show_bug.cgi?id=1581584 and it seems that this is
not a miscompilation where crash sites are merged. In GDB, it is clearly
visible that the correct crash site is reached and that ASan's signal handler
is called from there. Then ASan produces the wrong stack, suggesting there
might be a problem with ASan's unwinder.


This is a serious problem and has misled developers a few times already.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190917/118dc17c/attachment.html>