0

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?

4

1 回答 1

2

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

  • either instrumentation went wrong at some point
  • or (much less likely) instrumented code inadverently triggered some already existing critical bug

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).

于 2017-10-08T06:31:06.300 回答