Skip to content

glib-private: Check for LSAN support at runtime when controlling it

Marco Trevisan requested to merge 3v1n0/glib:lsan-dynamic-loading into main

GLib ignores various leaks that we don't consider as such (like the default gio modules) via the LSAN public interface, however those cases are always ignored when using a non-ASAN compiled glib is used by an ASAN-compiled binary.

This makes all the GLib-related programs to fail because of false positive leaks.

To avoid this, use the gcc extension for weak linking so that we can control ASAN and LSAN only if the symbols they provide are actually available at runtime.

The rationale behind this is that running a binary loading Gio modules is marked as leaking, for example:

❯ tmp-introspect6qnukp5s/FPrint-2.0 --introspect-dump=../_BUILD/libfprint/tmp-introspectf6kbg2qe/functions.txt,../_BUILD/libfprint/tmp-introspectf6kbg2qe/dump.xml


=================================================================
==34295==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 96 byte(s) in 1 object(s) allocated from:
    #0 0x7f39e3cde997 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
    #1 0x7f39e331a910 in g_malloc0 ../../glib/glib/gmem.c:163

Indirect leak of 51 byte(s) in 1 object(s) allocated from:
    #0 0x7f39e3cdefdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x7f39e331a8b8 in g_malloc ../../glib/glib/gmem.c:130

SUMMARY: AddressSanitizer: 147 byte(s) leaked in 2 allocation(s).

By using this GLib branch, all these false-positives are no more a problem.

Edited by Marco Trevisan

Merge request reports