(In reply to Jesse Schwartzentruber (:truber) from comment #7) > This may be a problem with ASan's unwinder. If I run the standalone test under `lldb` or `gdb`, the line of the crash is correct without `fprintf`. > > `ASAN_OPTIONS=fast_unwind_on_fatal=1` doesn't make a difference. Confirmed, in GDB everything looks normal, I even set a breakpoint inside the assembler code: 0x0000000000516fe0 <+848>: movl $0x26,0x0 // This is the first MOZ_REALLY_CRASH 0x0000000000516feb <+859>: callq 0x4e4db0 <__asan_handle_no_return> 0x0000000000516ff0 <+864>: callq 0x41a0f0 <abort@plt> 0x0000000000516ff5 <+869>: movl $0x2f,0x0 // This is the second MOZ_REALLY_CRASH 0x0000000000517000 <+880>: callq 0x4e4db0 <__asan_handle_no_return> 0x0000000000517005 <+885>: callq 0x41a0f0 <abort@plt> End of assembler dump. (gdb) break *0x0000000000516ff5 Breakpoint 1 at 0x516ff5: file test.cpp, line 47. (gdb) r Starting program: /srv/repos/mozilla-central-2/test.o [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". If you see a crash in line 38, then the compiler optimized our crash Calling testCrashFoo Breakpoint 1, main () at test.cpp:47 47 MOZ_REALLY_CRASH(__LINE__); // This is where the crash actually happens (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. main () at test.cpp:47 47 MOZ_REALLY_CRASH(__LINE__); // This is where the crash actually happens (gdb) c Continuing. AddressSanitizer:DEADLYSIGNAL ================================================================= ==5803==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000516ff5 bp 0x7fffffffe040 sp 0x7fffffffdf00 T0) ==5803==The signal is caused by a WRITE memory access. ==5803==Hint: address points to the zero page. #0 0x516ff4 in main /srv/repos/mozilla-central/test.cpp:38:5 #1 0x7ffff6a9bb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #2 0x41a3d9 in _start (/srv/repos/mozilla-central/test.o+0x41a3d9) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /srv/repos/mozilla-central/test.cpp:38:5 in main ==5803==ABORTING [Inferior 1 (process 5803) exited with code 01] (gdb) This seems really weird, maybe an ASan bug, but doesn't look like the kind of optimization problem I was expecting.
Bug 1581584 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jesse Schwartzentruber (:truber) from comment #7) > This may be a problem with ASan's unwinder. If I run the standalone test under `lldb` or `gdb`, the line of the crash is correct without `fprintf`. > > `ASAN_OPTIONS=fast_unwind_on_fatal=1` doesn't make a difference. Confirmed, in GDB everything looks normal, I even set a breakpoint inside the assembler code: 0x0000000000516fe0 <+848>: movl $0x26,0x0 // This is the first MOZ_REALLY_CRASH 0x0000000000516feb <+859>: callq 0x4e4db0 <__asan_handle_no_return> 0x0000000000516ff0 <+864>: callq 0x41a0f0 <abort@plt> 0x0000000000516ff5 <+869>: movl $0x2f,0x0 // This is the second MOZ_REALLY_CRASH 0x0000000000517000 <+880>: callq 0x4e4db0 <__asan_handle_no_return> 0x0000000000517005 <+885>: callq 0x41a0f0 <abort@plt> End of assembler dump. (gdb) break *0x0000000000516ff5 Breakpoint 1 at 0x516ff5: file test.cpp, line 47. (gdb) r Starting program: /srv/repos/mozilla-central/test.o [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". If you see a crash in line 38, then the compiler optimized our crash Calling testCrashFoo Breakpoint 1, main () at test.cpp:47 47 MOZ_REALLY_CRASH(__LINE__); // This is where the crash actually happens (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. main () at test.cpp:47 47 MOZ_REALLY_CRASH(__LINE__); // This is where the crash actually happens (gdb) c Continuing. AddressSanitizer:DEADLYSIGNAL ================================================================= ==5803==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000516ff5 bp 0x7fffffffe040 sp 0x7fffffffdf00 T0) ==5803==The signal is caused by a WRITE memory access. ==5803==Hint: address points to the zero page. #0 0x516ff4 in main /srv/repos/mozilla-central/test.cpp:38:5 #1 0x7ffff6a9bb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #2 0x41a3d9 in _start (/srv/repos/mozilla-central/test.o+0x41a3d9) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /srv/repos/mozilla-central/test.cpp:38:5 in main ==5803==ABORTING [Inferior 1 (process 5803) exited with code 01] (gdb) This seems really weird, maybe an ASan bug, but doesn't look like the kind of optimization problem I was expecting.