Leaking memory is impolite. It’s messy, it can suggest logic bugs, and thanks to AI grifters RAM is expensive.

Unfortunately C++ makes it rather easy to leak memory. Fortunately we have tools to find such leaks. One such tool is Leak Sanitizer (LSAN) from the Address Sanitizer (ASAN) family. It’s using compiler-based instrumentation for the code to reports any leaks after the program terminates.

KDE’s CI infrastructed has ASAN enabled for a while. However the leak sanitizer part was explicitly disabled, so no leaks were reported as part of the CI build and test run. This is because a number of projects have pre-exisiting memory leaks that would cause the C build to fail. Of course those should be fixed eventually, but in order to do that we need to know where they are. Also, for projects that currently don’t have any leaks we want to enforce keeping it that way.

A few lines of Python later KDE’s CI system now allows to enable LSAN on a per-project basis. The .kde-ci.yml file that governs CI builds in KDE gained a new option enable-lsan. It is off by default for now for compatibility, but we may consider enabling it by default eventually.

If enabled and any memory leak in a test is detected, that test and therefore the whole CI pipeline will fail.

Now once we found a leak, what can we do about it? There’s several options:

• Use good old delete/free(). Works, but is often rather error-prone.
• Use QObject’s parent mechanism. Works, but often frowned upon by C++ purists. Mostly makes sense for widget hierarchies.
• Smart pointers like std::unique_ptr/std::shared_ptr. These are great because they allow to express the ownership on an API level and make ownership transfers explicit. Often the best choice for business logic code.

LSAN is now enabled for some Frameworks CI builds, but ideally it would be enabled for all KDE projects. And of course any leaks found along the way should be fixed.

Happy leak-fixing!