weston/.gitlab-ci/leak-sanitizer.supp

14 lines
463 B
Plaintext
Raw Normal View History

Add leak sanitizer suppressions ASan will detect leaks also outside of the code we build, and sometimes that external code leaks and we cannot work around it. Then we need to suppress the leak reports to make our own ASan testing succeed. This commit only introduces the suppressions file, making use of it CI is for another time. This file is useful for manual targeted testing as below. Start by suppressing two functions what weston-keyboard client ends up calling, suppressing leak reports like these: Indirect leak of 96 byte(s) in 3 object(s) allocated from: #0 0x7fc109c3d518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518) #1 0x7fc109083d18 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x20d18) #2 0x7fc1090849a7 in FcPatternDuplicate (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x219a7) #3 0x7fc109adf93e (/lib/x86_64-linux-gnu/libcairo.so.2+0xbb93e) #4 0x7fc109adfc8d (/lib/x86_64-linux-gnu/libcairo.so.2+0xbbc8d) #5 0x7fc109aa02e7 in cairo_toy_font_face_create (/lib/x86_64-linux-gnu/libcairo.so.2+0x7c2e7) #6 0x7fc109aa856c in cairo_select_font_face (/lib/x86_64-linux-gnu/libcairo.so.2+0x8456c) #7 0x5603cb49a06a in redraw_handler ../../git/weston/clients/keyboard.c:378 #8 0x5603cb4b506b in widget_redraw ../../git/weston/clients/window.c:4520 #9 0x5603cb4b55da in surface_redraw ../../git/weston/clients/window.c:4578 #10 0x5603cb4b5750 in idle_redraw ../../git/weston/clients/window.c:4607 #11 0x5603cb4bebe3 in display_run ../../git/weston/clients/window.c:6525 #12 0x5603cb49e55d in main ../../git/weston/clients/keyboard.c:1054 #13 0x7fc1092a709a in __libc_start_main ../csu/libc-start.c:308 #14 0x5603cb499019 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19019) Indirect leak of 528 byte(s) in 51 object(s) allocated from: #0 0x7fc109b8e810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810) #1 0x7fc109082fc4 in FcValueSave (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x1ffc4) #2 0x7fc109083d2e (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x20d2e) #3 0x7fc1090852c7 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x222c7) #4 0x7fc10908c28b (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2928b) #5 0x7fc108603a15 (/lib/x86_64-linux-gnu/libexpat.so.1+0xba15) #6 0x7fc1086044bb (/lib/x86_64-linux-gnu/libexpat.so.1+0xc4bb) #7 0x7fc108601f8a (/lib/x86_64-linux-gnu/libexpat.so.1+0x9f8a) #8 0x7fc108602e7a (/lib/x86_64-linux-gnu/libexpat.so.1+0xae7a) #9 0x7fc108606a37 in XML_ParseBuffer (/lib/x86_64-linux-gnu/libexpat.so.1+0xea37) #10 0x7fc10908a0fa (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x270fa) #11 0x7fc10908a519 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x27519) #12 0x7fc10908a73a (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2773a) #13 0x7fc10908b48f (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x2848f) #14 0x7fc108603a15 (/lib/x86_64-linux-gnu/libexpat.so.1+0xba15) #15 0x7fc1086044bb (/lib/x86_64-linux-gnu/libexpat.so.1+0xc4bb) #16 0x7fc108601f8a (/lib/x86_64-linux-gnu/libexpat.so.1+0x9f8a) #17 0x7fc108602e7a (/lib/x86_64-linux-gnu/libexpat.so.1+0xae7a) #18 0x7fc108606a37 in XML_ParseBuffer (/lib/x86_64-linux-gnu/libexpat.so.1+0xea37) #19 0x7fc10908a0fa (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x270fa) #20 0x7fc10908a519 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x27519) #21 0x7fc10907c4b3 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x194b3) #22 0x7fc10907c715 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0x19715) #23 0x7fc10906e8e6 (/lib/x86_64-linux-gnu/libfontconfig.so.1+0xb8e6) #24 0x7fc109070928 in FcConfigSubstituteWithPat (/lib/x86_64-linux-gnu/libfontconfig.so.1+0xd928) #25 0x7fc109ae2d6b (/lib/x86_64-linux-gnu/libcairo.so.2+0xbed6b) #26 0x7fc109a8aba2 in cairo_scaled_font_create (/lib/x86_64-linux-gnu/libcairo.so.2+0x66ba2) #27 0x7fc109a50d1d (/lib/x86_64-linux-gnu/libcairo.so.2+0x2cd1d) #28 0x7fc109a53be0 (/lib/x86_64-linux-gnu/libcairo.so.2+0x2fbe0) #29 0x7fc109a4c1df (/lib/x86_64-linux-gnu/libcairo.so.2+0x281df) #30 0x7fc109aa8dab in cairo_text_extents (/lib/x86_64-linux-gnu/libcairo.so.2+0x84dab) #31 0x5603cb499af3 in draw_key ../../git/weston/clients/keyboard.c:329 #32 0x5603cb49a30c in redraw_handler ../../git/weston/clients/keyboard.c:392 #33 0x5603cb4b506b in widget_redraw ../../git/weston/clients/window.c:4520 #34 0x5603cb4b55da in surface_redraw ../../git/weston/clients/window.c:4578 #35 0x5603cb4b5750 in idle_redraw ../../git/weston/clients/window.c:4607 #36 0x5603cb4bebe3 in display_run ../../git/weston/clients/window.c:6525 #37 0x5603cb49e55d in main ../../git/weston/clients/keyboard.c:1054 #38 0x7fc1092a709a in __libc_start_main ../csu/libc-start.c:308 #39 0x5603cb499019 in _start (/home/pq/build/weston-meson/clients/weston-keyboard+0x19019) With the command line ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \ LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \ ./tests/test-viewporter test_viewporter_double_create Suppressions used: count bytes template 5 357 cairo_select_font_face 130 9104 cairo_text_extents Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-05-24 14:07:02 +03:00
# AddressSanitizer memory leak suppressions
# This leaks in Debian's fontconfig/Xwayland setup. We add the entire
# fontconfig library because turning off fast unwind -- required to catch other
# originating leaks from fontconfig; would stall our tests timing them out.
leak:libfontconfig
CI: work around LeakSanitizer crashes with use_tls=0 Without this fix, we have randomly been getting CI failures due to LeakSanitizer itself crashing after all the tests in a program have succeeded. This has been happening randomly for a long time, but https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1486 made it very reliably repeatable in the job x86_64-debian-full-build (and no other job) in the test-subsurface-shot program. --- Fixture 2 (GL) ok: passed 4, skipped 0, failed 0, total 4 Tracer caught signal 11: addr=0x1b8 pc=0x7f6b3ba640f0 sp=0x7f6b2cc77d10 ==489==LeakSanitizer has encountered a fatal error. I was also able to get a core file after twiddling, but there it ended up with lsan aborting itself rather than a segfault. We got some clues that use_tls=0 might work around this, from https://github.com/google/sanitizers/issues/1342 https://github.com/google/sanitizers/issues/1409 and some other projects that have cargo-culted the same workaround. Using that cause more false leaks to appear, so they need to be suppressed. I suppose we are not interested in catching leaks in glib using code, so I opted to suppress g_malloc0 altogether. Pinpointing it better might have required much more slower stack tracing. wl_shm_buffer_begin_access() uses TLS, so no wonder it gets flagged. ld-*.so is simply uninteresting to us, and it got flagged too. Since this might have been fixed already in LeakSanitizer upstream, who knows, leave some notes to revisit this when we upgrade that in CI. This fix seems to make the branch of https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1486 in my quick testing. Suggested-by: Derek Foreman <derek.foreman@collabora.com> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2024-04-09 15:41:45 +03:00
# Workarounds for the LeakSanitizer use_tls=0 workaround,
# see tests/meson.build
leak:wl_shm_buffer_begin_access
leak:g_malloc0
leak:sysprof_collector_get
CI: work around LeakSanitizer crashes with use_tls=0 Without this fix, we have randomly been getting CI failures due to LeakSanitizer itself crashing after all the tests in a program have succeeded. This has been happening randomly for a long time, but https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1486 made it very reliably repeatable in the job x86_64-debian-full-build (and no other job) in the test-subsurface-shot program. --- Fixture 2 (GL) ok: passed 4, skipped 0, failed 0, total 4 Tracer caught signal 11: addr=0x1b8 pc=0x7f6b3ba640f0 sp=0x7f6b2cc77d10 ==489==LeakSanitizer has encountered a fatal error. I was also able to get a core file after twiddling, but there it ended up with lsan aborting itself rather than a segfault. We got some clues that use_tls=0 might work around this, from https://github.com/google/sanitizers/issues/1342 https://github.com/google/sanitizers/issues/1409 and some other projects that have cargo-culted the same workaround. Using that cause more false leaks to appear, so they need to be suppressed. I suppose we are not interested in catching leaks in glib using code, so I opted to suppress g_malloc0 altogether. Pinpointing it better might have required much more slower stack tracing. wl_shm_buffer_begin_access() uses TLS, so no wonder it gets flagged. ld-*.so is simply uninteresting to us, and it got flagged too. Since this might have been fixed already in LeakSanitizer upstream, who knows, leave some notes to revisit this when we upgrade that in CI. This fix seems to make the branch of https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1486 in my quick testing. Suggested-by: Derek Foreman <derek.foreman@collabora.com> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2024-04-09 15:41:45 +03:00
leak:/ld-*.so*