Sometimes valgrind can report the right problem with the wrong stack trace:
make && sudo valgrind --db-attach=yes --leak-check=full --track-origins=yes --show-reachable=yes ./dist/Debug/cbadaemon
==4423== Memcheck, a memory error detector
==4423== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4423== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4423== Command: ./dist/Debug/cbadaemon
==4423==
==4423== Conditional jump or move depends on uninitialised value(s)
==4423== at 0x4922C47: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:38)
==4423== by 0x804E91A: ServerContext::ServerContext() (ServerContext.cpp:11)
==4423== by 0x804EB92: ServerCore::ServerCore(int, char**) (ServerCore.cpp:15)
==4423== by 0x804F627: main (main.cpp:57)
==4423== Uninitialised value was created by a heap allocation
==4423== at 0x48D273C: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==4423== by 0x804F60F: main (main.cpp:57)
==4423==
==4423==
==4423== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
(gdb) bt
#0 0x04922c47 in __pthread_mutex_unlock_usercnt (mutex=0x75e80d8, decr=1) at pthread_mutex_unlock.c:38
#1 0x0805d15b in RequestManager::RequestManager (this=0x75e8030) at src/transac/RequestManager.cpp:27
#2 0x0804e91b in ServerContext::ServerContext (this=0x75e802c) at src/server/ServerContext.cpp:11
#3 0x0804eb93 in ServerCore::ServerCore (this=0x75e8028, argc=1, argv=0xfef79b94) at src/server/ServerCore.cpp:15
#4 0x0804f628 in main (argc=1, argv=0xfef79b94) at src/main.cpp:57
(gdb) q
And it’s not an optimization problem as it was compiled with:
-c -m32 -g -rdynamic -O0 -fPIC -Wall -Werror