Today, we release rsyslog 8.31. This is probably one of the biggest releases in the past couple of years. While it also offers great new functionality, what really important about it is the focus on further improved software quality.
Let’s get a bit down on it. First let’s mention some important new features:
And then we have a set of several hundred commits concerned with improved software quality:
- testbench dynamic tests have been extended
- coverage of different compilers and compiler options has been enhanced
- more modules are automatically scanned by static analysis
- daily Coverity scans were added to the QA system, which have proofen to be a very useful addition
- more aggressive and automated testing with threading debuggers (valgrind’s helgrind and clang thread sanitizer) has been added, also with great success
- as a result of these actions, we could find and fix many small software defects.
- and there also have been some big and important fixes, namely for imjournal, omelasticsearch, mmdblookup and the rsyslog core
Many users were involved in finding and fixing bugs,
many of which all I do know from is there github handle. So rather than highlighting just some of them, I would like to refer to the github milestone issue tracker
where all can be found. My sincere thanks to everyone for all their support!
I consider rsyslog release 8.31 a major step forward in our QA policy. We already had improved quite a bit and the state was already pretty good. However, with the changes introduced in 8.31, we make a big step forward, into a kind of next-gen QA policy. Of course, QA is a journey and not a “do once” target. So expect more good stuff upcoming in the next releases. We are not done yet!
I would like to use this opportunity to express a personal “thank yo” to Thomas Deutschmann
, also know as Whissi for all his good advice
and sometimes strong words that drive use towards better quality
. While many folks have helped us with this, Whissi is consistenytly insisting on good QA policies for a long time now, and he always was persistent in fighting with me when I did not understand the value or did not want to. Whissi, I admit I sometimes wasn’t too fond of you, but believe me, at the end of the day I *really*
value what you are doing. You have my deepest respect. Looking forward to many more years of discussions!
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)
- 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”.
This is how you can automate Coverity Scan using Travis CI – especially if you have a complex build matrix:
- create an additional matrix entry you will exclusively use for submission to Coverity
- make sure you use your regular git master branch for the scans (so you can be sure you scan the real thing!)
- schedule a Travis CI cron job (daily, if permitted by project size and Coverity submission allowance)
- In that cron job, on the dedicated Coverity matrix entry:
- cache Coverity’s analysis tools on your own web site, download them from there during Travis CI VM preparation (Coverity doesn’t like too-frequent downloads)
- prepare your project for compilation as usual (autoreconf, configure, …) – ensure that you build all source units, as you want a full scan
- run the cov-int tool according to Coverity instructions
- tar the build result
- use the “manual” wget upload capability (doc on Coverity submission web form); make sure you use a secure Travis environment variable for your Coverity token
- you will receive scan results via email as usual – if you like, automate email-to-issue creation for newly found defects
Continue reading “Automating Coverity Scan with a complex TravisCI build matrix”