Finding threading bugs is hard. Clang thread sanitizer makes it easier. The thread sanitizer instruments the to-be-tested code and emits useful information about actions that look suspicious (most importantly data races). This is a great aid in development and for QA. Thread sanitizer is faster than valgrind’s helgind, which makes it applicable to more use cases. Note however that helgrind and thread sanitizer sometimes each detect issues that the other one does not.
This is how thread sanitizer can be activated:
- install clang package (the OS package is usually good enough, but if you want to use clang 5.0, you can obtain packages from http://apt.llvm.org/)
- export CC=clang // or CC=clang-5.0 for the LLVM packages
- export CFLAGS=”-g -fsanitize=thread -fno-omit-frame-pointer”
- re-run configure (very important, else CFLAGS is not picked up!)
- make clean (important, else make does not detect that it needs to build some files due to change of CFLAGS)
- make
- install as usual
If you came to this page trying to debug a rsyslog problem, we strongly suggest to run your instrumented version interactively. To do so:
- stop the rsyslog system service
- sudo -i (you usually need root privileges for a typical rsyslogd configuration)
- execute /path/to/rsyslogd -n …other options…
here “/path/to” may not be required and often is just “/sbin” (so “/sbin/rsyslogd”)
“other options” is whatever is specified in your OS startup scripts, most often nothing - let rsyslog run; thread sanitizer will spit out messages to stdout/stderr (or nothing if all is well)
- press ctl-c to terminate rsyslog run
Note that the thread sanitizer will display some false positives at the start (related to pthread_cancel, maybe localtime_r). The stack trace shall contain exact location info. If it does not, the ASAN_SYMBOLIZER is not correctly set, but usually it “just works”.
Doc on thread sanitizer ist available here: https://clang.llvm.org/docs/ThreadSanitizer.html