I have been trying to figure out the root cause for a segmentation fault that I see while running my application with Address Sanitizer(ASAN) enabled. When I attach GDB and debug the application, I see the segfault being received right at the beginning of the method:
Minimal code:
int TimerScope::switchMode() {
doCapture(mode)
}
> int TimerScope::doCapture(Mode captureMode) { <---- segfault here
if(handle == -1)
return 0;
XLOG(TRACE, image(this));
..
}
Note that I don't see the issue for a build without address sanitizer. I have looked at different aspects of this issue (like looking for garbage address of variables, running valgrind/UBSAN etc) without any luck. Currently I am looking into the assembly code to see if there are any clues there. With GDB, when I print the location of the segfault, this is what I get:
(gdb) p $_siginfo._sifields._sigfault.si_addr
$5 = (void *) 0x7fe4d3908fb8
The assembly code is as given below, which is executing some logic as the method TimerScope::doCapture
gets called:
0x7fe69595f65e <_ZN7ts9TimerScope9doCaptureENS_8ModeE> endbr64 │
│ 0x7fe69595f662 <_ZN7ts9TimerScope9doCaptureENS_8ModeE 4> push %rbp │
│ 0x7fe69595f663 <_ZN7ts9TimerScope9doCaptureENS_8ModeE 5> mov %rsp,%rbp │
│ 0x7fe69595f666 <_ZN7ts9TimerScope9doCaptureENS_8ModeE 8> push %r15 │
│ 0x7fe69595f668 <_ZN7ts9TimerScope9doCaptureENS_8ModeE 10> push %r14 │
│ 0x7fe69595f66a <_ZN7ts9TimerScope9doCaptureENS_8ModeE 12> push %r13 │
│ 0x7fe69595f66c <_ZN7ts9TimerScope9doCaptureENS_8ModeE 14> push %r12 │
│ 0x7fe69595f66e <_ZN7ts9TimerScope9doCaptureENS_8ModeE 16> push %rbx │
│ 0x7fe69595f66f <_ZN7ts9TimerScope9doCaptureENS_8ModeE 17> sub $0x1000,%rsp │
│ 0x7fe69595f676 <_ZN7ts9TimerScope9doCaptureENS_8ModeE 24> orq $0x0,(%rsp) │
│ 0x7fe69595f67b <_ZN7ts9TimerScope9doCaptureENS_8ModeE 29> sub $0x1a8,%rsp │
│ > 0x7fe69595f682 <_ZN7ts9TimerScope9doCaptureENS_8ModeE 36> mov %rdi,-0x1198(%rbp) │
│ 0x7fe69595f689 <_ZN7ts9TimerScope9doCaptureENS_8ModeE 43> mov %esi,