Valgrind might be wrong

Sometimes valgrind can report the right problem with the wrong stack trace:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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
1
2
3
4
5
6
7
(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:

1
-c -m32 -g -rdynamic -O0 -fPIC -Wall -Werror

Leave a Reply

Your email address will not be published. Required fields are marked *