mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-22 01:59:26 +00:00
Code Issues Releases Wiki Activity
bind/.tsan-suppress

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

10 lines
208 B
Plaintext
Raw Permalink Normal View History

Change images for TSAN jobs Fedora 38 and Debian "bullseye" images were "forked" to images used only for TSAN CI jobs. The new images contain TSAN-aware liburcu that does not fit well with ASAN CI jobs for which original images were also used. Also, drop liburcu-related TSAN suppressions because they are unnecessary with TSAN-aware liburcu.
2023-05-26 10:50:58 +02:00
# Uninstrumented libraries
called_from_lib:libfstrm.so
race:dummyrpz
Suppress FreeBSD-specific TSAN false-positive data race TSAN reports a data race in FreeBSD's memset(), called by its __crt_calloc() memory allocation function. There is a very similar bug report [1] in FreeBSD bug tracker, and an existing code-review [2] that tries to address an issue, the description of which is very similar to what we are seeing. Suppress this report by adding its signature to '.tsan-suppress'. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282794 [2] https://reviews.freebsd.org/D28536?id=86694
2025-04-01 13:36:33 +00:00
# FreeBSD false-positive, see GL#5267
race:libexec/rtld-elf/rtld_malloc.c
Suppress FreeBSD-specific TSAN false-positive lock-order-inversion TSAN reports a lock-order-inversion (potential deadlock) issue in add_trace_entry(): WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) Cycle in lock order graph: M0001 (0x000000000001) => M0002 (0x000000000002) => M0001 Mutex M0002 acquired here while holding mutex M0001 in main thread: #0 _pthread_mutex_lock /usr/src/contrib/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1342:3 #1 add_trace_entry lib/isc/mem.c:210:2 #2 isc__mem_get lib/isc/mem.c:606:2 #3 isc_buffer_allocate lib/isc/./include/isc/buffer.h:1080:23 #4 pushandgrow lib/isc/lex.c:321:3 #5 isc_lex_gettoken lib/isc/lex.c:445:22 #6 cfg_gettoken lib/isccfg/parser.c:3490:11 #7 cfg_parse_mapbody lib/isccfg/parser.c:2230:3 #8 cfg_parse_obj lib/isccfg/parser.c:247:11 #9 parse2 lib/isccfg/parser.c:628:11 #10 cfg_parse_file lib/isccfg/parser.c:668:11 #11 load_configuration bin/named/server.c:8069:13 #12 run_server bin/named/server.c:9518:2 #13 isc__async_cb lib/isc/async.c:110:3 #14 uv__async_io /tmp/libuv-1.50.0/src/unix/async.c:208:5 #15 uv__io_poll /tmp/libuv-1.50.0/src/unix/kqueue.c:369:9 #16 uv_run /tmp/libuv-1.50.0/src/unix/core.c:460:5 #17 loop_thread lib/isc/loop.c:327:6 #18 thread_body lib/isc/thread.c:89:8 #19 isc_thread_main lib/isc/thread.c:124:2 #20 isc_loopmgr_run lib/isc/loop.c:513:2 #21 main bin/named/main.c:1469:2 Mutex M0001 previously acquired by the same thread here: #0 _pthread_mutex_lock /usr/src/contrib/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1342:3 #1 _flockfile /usr/src/lib/libc/stdio/_flock_stub.c:72:3 #2 cfg_gettoken lib/isccfg/parser.c:3490:11 #3 cfg_parse_mapbody lib/isccfg/parser.c:2230:3 #4 cfg_parse_obj lib/isccfg/parser.c:247:11 #5 parse2 lib/isccfg/parser.c:628:11 #6 cfg_parse_file lib/isccfg/parser.c:668:11 #7 load_configuration bin/named/server.c:8069:13 #8 run_server bin/named/server.c:9518:2 #9 isc__async_cb lib/isc/async.c:110:3 #10 uv__async_io /tmp/libuv-1.50.0/src/unix/async.c:208:5 #11 uv__io_poll /tmp/libuv-1.50.0/src/unix/kqueue.c:369:9 #12 uv_run /tmp/libuv-1.50.0/src/unix/core.c:460:5 #13 loop_thread lib/isc/loop.c:327:6 #14 thread_body lib/isc/thread.c:89:8 #15 isc_thread_main lib/isc/thread.c:124:2 #16 isc_loopmgr_run lib/isc/loop.c:513:2 #17 main bin/named/main.c:1469:2 Mutex M0001 acquired here while holding mutex M0002 in main thread: #0 _pthread_mutex_lock /usr/src/contrib/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1342:3 #1 _flockfile /usr/src/lib/libc/stdio/_flock_stub.c:72:3 #2 print_active lib/isc/mem.c:629:3 #3 isc_mem_stats lib/isc/mem.c:694:2 #4 main bin/named/main.c:1498:4 Mutex M0002 previously acquired by the same thread here: #0 _pthread_mutex_lock /usr/src/contrib/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1342:3 #1 isc_mem_stats lib/isc/mem.c:668:2 #2 main bin/named/main.c:1498:4 SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) lib/isc/mem.c:210:2 in add_trace_entry In the first stack frame ('M0001'->'M0002' lock order) cfg_gettoken() uses flockfile() to lock 'M0001' for the 'FILE' object associated with the configuration file (e.g. the configuration file itself and whatever it includes, like a zone database), then it locks a memory context mutex M0002. In the other stack frmae ('M0002'->'M0001' lock order) isc_mem_stats() locks a memory context mutex M0002, then it uses fprintf(), which internally locks a 'M0001' mutex with flockfile() to write into the 'named.memstats' memory statistics file. While it is true that in one case a lock in the 'isc_mem_t' structure is locked first, and then a lock in the 'FILE' structure is locked second, and in the the second case it is the other way around, this isn't an issue, because those are 'FILE' structures for totally different files, used in different parts of the code. It was also manually confirmed that 'named.memstats' doesn't get processed by cfg_gettoken(), and is used only in the second stack frame's code flow when named is exiting.
2025-04-02 08:38:58 +00:00
# FreeBSD false-positive, see GL#5266
deadlock:add_trace_entry
Reference in New Issue Copy Permalink