Valgrind reports warnings for libc when 'grinding an rdkafka application. Example trace: https://github.com/mcandre/docker-rdkafka-valgrind/blob/0a3e71502e7b0636f48959cb2671c054d845f159/README.md#examples Example suppressions: https://github.com/mcandre/docker-rdkafka-valgrind/blob/1b3d885a9ac9d1a9c2faee8f27bab137d7acfaa3/rdkafka.supp
Reproducer (more or less): #include <stdlib.h> #include <pthread.h> void *p = &pthread_create; int main(int argc, char **argv) { malloc (10); return 0; } Compile without optimization and link with -static -lpthread. I think the static TLS allocation is considered uninitialized by valgrind for some reason. I do not know if valgrind is right here and the memory is actually uninitialized, or if the kernel guarantees that it is zero-initialized. Fresh memory returned by brk is generally zero-initialized, but I don't know what happens if the brk pointer is decremented and incremented again (say by parasite code in the process—nothing else can run so early during process setup). Would that cause the kernel to clear the re-exposed memory region?
Try without -static. With -static you'll get: ==16205== Conditional jump or move depends on uninitialised value(s) ==16205== at 0x435B16: __linkin_atfork (in /tmp/tp) ==16205== by 0x420273: ptmalloc_init.part.8 (in /tmp/tp) ==16205== by 0x4205FD: malloc_hook_ini (in /tmp/tp) ==16205== by 0x47CC0D: _dl_important_hwcaps (in /tmp/tp) ==16205== by 0x478340: _dl_init_paths (in /tmp/tp) ==16205== by 0x43708B: _dl_non_dynamic_init (in /tmp/tp) ==16205== by 0x437F23: __libc_init_first (in /tmp/tp) ==16205== by 0x41044D: (below main) (in /tmp/tp) ==16205== Uninitialised value was created ==16205== at 0x472D1C: brk (in /tmp/tp) ==16205== by 0x431FA4: sbrk (in /tmp/tp) ==16205== by 0x4109F3: __libc_setup_tls (in /tmp/tp) ==16205== by 0x401D9A: __pthread_initialize_minimal (in /tmp/tp) ==16205== by 0x410405: (below main) (in /tmp/tp) Note that valgrind assumes memory returned by brk is not initialized.