I have a python module that uses an external C++ library using a C++ extension build with distutils. When I compile the C++ library with the address sanitizer, -fsanitize option of GCC, I get a segfault when running unit tests. Now, initially I thought that it was because me using different compiler options for the two binaries, the C++ python extension and the library but now I am more and more convinced that this is because the address sanitizer found an error in the library and triggered a seg fault, as explained here. This is also supported by the fact that if I compile the C++ library without the address sanitizer, everything works fine. When I run unit tests, the program outputs very little information:
./run_unit_tests
Segmentation fault (core dumped)
Even looking at the core dump I was able to find only a stack trace pointing to the C++ library but no mention of address sanitizer.
I have tried to use ASAN_OPTIONS to redirect the sanitizer output to a file but the sanitizer apparently does not pick up the options:
ASAN_OPTIONS=help=1 ./run_unit_tests
Segmentation fault (core dumped)
What strategy should I take here to confirm that the seg fault coms from the sanitizer and possibly discover what kind of error it is?
First a few clarifications:
this is because the address sanitizer found an error in the library and triggered a seg fault
When Asan detects an error, it will always emit a friendly error message. Segfault means that
This is also supported by the fact that if I compile the C++ library with undefined behavior sanitizer, everything is working fine
UBSan is much simpler than ASan so in general you can not really share conclusions about them.
I have tried to use ASAN_OPTIONS to redirect the sanitizer output to a file but the sanitizer apparently does not pick up the options:
The fact that help=1
fails tells us that sanitized app segfaulted at early startup, before Asan was able to parse ASAN_OPTIONS
and react appropriately. This usually happens when there is some basic issue in how Asan was enabled.
My guess is that you miss LD_PRELOAD=path/to/libasan.so
environment setting which is required when when applying Asan to a single DSO instead of main application (as is the case with sanitized C/C++ plugins for interpreters, check Asan FAQ).
If this does not help, I suggest to provide more information (e.g. GCC version, symbolized stack at the point of segv).