Deep dive into Clang sanitizer testing with MariaDB (Post Event)

magnifying glass on computer screen, finding a bug in the code

Earlier I posted that this presentation was about to happen, and it did! I presented to a keen audience of over 20 people live, and number who watched later (it was in a rather early US time, however attracted a number of attendees from Europe, India, Thailand all the way to east of Australia at UTC+10:30.

Below is the video, and the slide outline is available.

The journey to this presentation began as a request to update our Clang version that we use in Buildbot, MariaDB’s CI system. During this journey, some MariaDB server faults where fixed, and some changes to MariaDB build process to make it easier and more straight forward. It wasn’t all a smooth journey but this resulted in a LLVM bug report that we found a work around for. This also resulted in a patch to patch, to remove some excessive output during some of our test cases generally.

The process to build a MSAN / clang testing container always had the end user usage there as secondary but important goal as the MemorySanitizer environment on instrumented libraries is particular onerous to create. To aid this there was a /etc/motd documentation added along with rr for debugging. Our documentation was updated and all the video flowed from those.

This particular deep dive covered:

  • Basics of MemorySanitizer, Address Santizer and Undefined Behavour Sanitizer;
  • How memory sanitizer uses shadow memory and the importance of instrumented libraries;
  • How to configure, compile and run MariaDB in the buildbot MSAN container;
  • How a MSAN generated stack traces can be used to follow an uninitialized usage all the way back though to where it was first allocated, allowing for simple patch with basic coding skills
  • How RR within a container to debug how MariaDB executes a particular test; and how watch points on shadow memory can trace its initialized and uninitialized transitions.
  • How to write very limited exceptions for the when undefined memory is written and read form file, and ensuring it has limited scope.
  • How to take information within a container to create a bug report.
  • How to compile Address Sanitizer and Undefined Behavour Sanitizers together and run tests to achieve a measure safety approach there.
  • And concluding the the current state of all these sanitizer in the MariaDB codebase and our Buildbot CI system.

As previous stated, if you have an interest in developing, testing or fuzzing MariaDB these will provide some very useful points on which to report and resolve memory safety issues.

Lastly this work would not have been possible without:

  • Marko Mäkelä; his work getting a environment and making the code MemorySanitizer safe. Its worth reading Efficient Use of rr to Analyze and Fix MemorySanitizer Errors;
  • The developers of clang and rr that have everyone such wonderful mature technology to use;
  • MariaDB Foundation Sponsor; including our infrastructure sponsors of Buildbot.

Image credit: Open Source.com Attribution-ShareAlike 4.0 International