Re: Sanitizers -- status & how to use?

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

> Given the target, this means gcc 10.5.0 ("nb3") is the default
> compiler.  I think I'm able to read the gcc man page, which
> points towards -fsanitize=thread, and that it cannot be combined
> with either of the "address" or "leak" sanitizers, and googling a
> bit brings me to

My first attempt with

diff --git a/bind920/Makefile b/bind920/Makefile
index d270b440ea..0016c6f62a 100644
--- a/bind920/Makefile
+++ b/bind920/Makefile
@@ -29,6 +29,11 @@ GNU_CONFIGURE=               yes
 CHECK_FILES_SKIP=      bin/tests/system/system-test-driver.sh
 MAKE_ENV+=             WRKDIR=${WRKDIR} PREFIX=${PREFIX}
 
+# Try to use thread sanitizer
+PKGSRC_COMPILER=       clang
+CFLAGS+=               -g
+CFLAGS+=               -fsanitize=thread
+
 .if ${OPSYS} == "Linux" && !exists(/usr/include/sys/capability.h)
 CONFIGURE_ARGS+=               --disable-linux-caps
 .endif

failed spectacularly on the first attempt at running an
executable built with clang, mirrored by this:

% cat t.c
#include <stdio.h>
int
main (void)
{
FILE *f = fopen ("conftest.out", "w");
 if (!f)
  return 1;
 return ferror (f) || fclose (f) != 0;

  ;
  return 0;
}
% clang --version
clang version 18.1.8
Target: x86_64-unknown-netbsd10.99
Thread model: posix
InstalledDir: /usr/pkg/bin
% clang -o conftest -O2 -g -fsanitize=thread -pthread -I/usr/include -I/usr/pkg/include -I/usr/include -I/usr/pkg/include -Wl,-zrelro -pthread -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib t.c
% ./conftest
Segmentation fault (core dumped)
% gdb -q conftest conftest.core
Reading symbols from conftest...
[New process 22062]
Core was generated by `conftest'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) where
#0  0x0000000000000000 in ?? ()
#1  0x000000000043f08c in ___interceptor_pthread_mutex_lock (m=0x70b2a18153e0)
    at /usr/pkgsrc/lang/compiler-rt/work/compiler-rt-18.1.8.src/lib/tsan/rtl/tsan_interceptors_posix.cpp:1342
#2  0x000070b2a1610be6 in __register_frame_info_bases ()
   from /usr/lib/libgcc_s.so.1
#3  0x000070b2a1a462c6 in ?? () from /usr/lib/libc.so.12
#4  0x000070b2a2e62400 in ?? ()
#5  0x000070b2a1a40e79 in _init () from /usr/lib/libc.so.12
#6  0x0000000000400270 in ?? ()
#7  0x00007f7e2c8063d9 in _rtld_call_init_function () from /libexec/ld.elf_so
#8  0x00007f7e2c8066d7 in _rtld_call_init_functions () from /libexec/ld.elf_so
#9  0x00007f7e2c80710a in _rtld () from /libexec/ld.elf_so
#10 0x00007f7e2c800803 in rtld_start () from /libexec/ld.elf_so
#11 0x0000000000000000 in ?? ()
(gdb) 

Trying this with gcc:

% gcc -o conftest -O2 -g -fsanitize=thread -pthread -I/usr/include -I/usr/pkg/include -I/usr/include -I/usr/pkg/include -Wl,-zrelro -pthread -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib t.c
% ./conftest
This sanitizer is not compatible with enabled ASLR
% 

Oh, well:

% sysctl -a | grep aslr
security.pax.aslr.enabled = 1
security.pax.aslr.global = 1
security.pax.aslr.debug = 0
security.pax.aslr.flags = 0
security.pax.aslr.rand = 0
security.pax.aslr.mmap_len = 32
security.pax.aslr.stack_len = 16
security.pax.aslr.exec_len = 12
% su
# exec tcsh
# sysctl -w security.pax.aslr.enabled=0
security.pax.aslr.enabled: 1 -> 0
# z

Suspended
% ./conftest
% echo $status
0
% 

So, let's re-try with clang:

% clang -o conftest -O2 -g -fsanitize=thread -pthread -I/usr/include -I/usr/pkg/include -I/usr/include -I/usr/pkg/include -Wl,-zrelro -pthread -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib t.c
% ./conftest
Segmentation fault (core dumped)
% gdb -q conftest conftest.core
Reading symbols from conftest...
[New process 10288]
Core was generated by `conftest'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) where
#0  0x0000000000000000 in ?? ()
#1  0x000000000043f08c in ___interceptor_pthread_mutex_lock (m=0x7f7ff64153e0)
    at /usr/pkgsrc/lang/compiler-rt/work/compiler-rt-18.1.8.src/lib/tsan/rtl/tsan_interceptors_posix.cpp:1342
#2  0x00007f7ff6210be6 in __register_frame_info_bases ()
   from /usr/lib/libgcc_s.so.1
#3  0x00007f7ff66462c6 in ?? () from /usr/lib/libc.so.12
#4  0x00007f7ff7efc400 in ?? ()
#5  0x00007f7ff6640e79 in _init () from /usr/lib/libc.so.12
#6  0x0000000000400270 in ?? ()
#7  0x00007f7ff7c063d9 in _rtld_call_init_function () from /libexec/ld.elf_so
#8  0x00007f7ff7c066d7 in _rtld_call_init_functions () from /libexec/ld.elf_so
#9  0x00007f7ff7c0710a in _rtld () from /libexec/ld.elf_so
#10 0x00007f7ff7c00803 in rtld_start () from /libexec/ld.elf_so
#11 0x0000000000000000 in ?? ()
(gdb) 

So, "This does not work with clang / LLVM" apparently"; looks
like I'll have to put my hope to gcc.  Or am I doing something
wrong?  Anyone want to make a prediction about how that'll turn
out with the in-tree gcc 10.5.0?

Regards,

- Håvard