Category: development

Posted on

Using Local AI Review to Save CI Time, Money, and Nerves

You know, I like efficient processes. After all, that was one reason that I wrote rsyslog. Which, btw, nowadays is increasingly useful and cost-saving as an ETL/ingestion issue for its speed. So no surprise, I also like efficient workflows.

Terminal showing iterative local AI code review with cubic CLI, code fixes, rebuilds, and test runs before final commit.”

We strongly believe in CI. Especially with AI code generation, it is your ultimate safeguard. However, CI is costly, and AI review usually runs max once per CI run.

So I have paired that review with some local test execution and review. Nowadays of course AI assisted. I usually use CLI tools for their efficiency. As part of the post-build process, I make the AI run various checks. The last one is a full review. I often use cubic for that, because it provides very good results to me.

Continue reading “Using Local AI Review to Save CI Time, Money, and Nerves”
Posted on

The clang thread sanitizer

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