Drd - How to interpret this “Other segment” call stack?

Question

I'm running drd to catch data races in some legacy code. I know drd works on segments and not on single instructions and I was expecting to find a common point between the call stack of Other segment start and Other segment end , but this is not the case.

==12982== Thread 5:
==12982== Conflicting load by thread 5 at 0x0060e6b0 size 8
==12982==    at 0x4F2CBEB: std::_Rb_tree<int, std::pair<int const, CMNSSrvNesting*>, std::_Select1st<std::pair<int const, CMNSSrvNesting*> >, std::less<int>, std::allocator<std::pair<int const, CMNSSrvNesting*> > >::find(int const&) (stl_tree.h:502)
==12982==    by 0x4F27FBE: CMetiMNSSrv::GetSockDataPtr(int, int) (stl_map.h:822)
==12982==    by 0x4F2A8E2: CMetiMNSSrv::ServerMessagesHandler(t_blkLx, unsigned char*, CAsyncSocketL*, void*) (MetiMNSSrv.cpp:957)
==12982==    by 0x507A705: CAsyncSocketL::SockHandlerCallback(void*, t_blkLx*, unsigned char*) (TWSocketLinux.cpp:417)
==12982==    by 0x518F2D1: _SK_Connection_handler (twlsocket.c:434)
==12982==    by 0x4C30E7B: ??? (in /usr/lib/valgrind/vgpreload_drd-amd64-linux.so)
==12982==    by 0x685F181: start_thread (pthread_create.c:312)
==12982==    by 0x6B6F47C: clone (clone.S:111)
==12982== Allocation context: BSS section of /home/teseo/bin/LiMNEGUI/LiMNEGUI
==12982== Other segment start (thread 4)
==12982==    at 0x4C34544: pthread_mutex_unlock (in /usr/lib/valgrind/vgpreload_drd-amd64-linux.so)
==12982==    by 0x5135589: pthreadMutexLeave (sqlite3.c:18998)
==12982==    by 0x5122E3F: sqlite3_mutex_leave (sqlite3.c:18451)
==12982==    by 0x5123321: sqlite3_free (sqlite3.c:19929)
==12982==    by 0x5168349: sqlite3LeaveMutexAndCloseZombie (sqlite3.c:122082)
==12982==    by 0x51685A4: sqlite3Close (sqlite3.c:121948)
==12982==    by 0x51685C5: sqlite3_close (sqlite3.c:121961)
==12982==    by 0x518FA7F: Sqlite3Db::~Sqlite3Db() (twnestshared.cpp:89)
==12982==    by 0x519A346: CIniFile::SetValue(std::string const&, std::string const&, std::string const&, std::string const&) (twnestshared.cpp:1264)
==12982==    by 0x519B148: CMetiReg::SerialItem(char const*, unsigned int*, unsigned int, char const*) (twnestshared.cpp:1431)
==12982==    by 0x4F22D6F: CMetiMNSSrv::SetRegistryVal(char const*, char const*, unsigned int, bool) (MetiMNSSrv.cpp:72)
==12982==    by 0x4F24BAE: CMNSSrvNesting::SetLastOperationTime(bool, unsigned int, unsigned long long, unsigned long long) (MetiMNSSrv.cpp:616)
==12982== Other segment end (thread 4)
==12982==    at 0x68667EB: recv (recv.c:33)
==12982==    by 0x518E736: SK_GetBytes (socket2.h:44)
==12982==    by 0x518E8D6: SK_GetBlock (twlsocket.c:858)
==12982==    by 0x518F19D: _SK_Connection_handler (twlsocket.c:407)
==12982==    by 0x4C30E7B: ??? (in /usr/lib/valgrind/vgpreload_drd-amd64-linux.so)
==12982==    by 0x685F181: start_thread (pthread_create.c:312)
==12982==    by 0x6B6F47C: clone (clone.S:111)

How should I interpret these information? Where can I find the point where thread 4 conflicts with thread 5 ?

Edit : other info

The program has been compiled with GCC 4.8, debug info -g3 and optimization -Og .

Answer 1

drd cannot give the precise location of the conflict in the other thread.

In the above drd error output, the 2 segment start/end are limited to 12 program counters by default. You can change this by using the option --num-callers=

If you want to have more precise information, you could try --tool=helgrind that can record the precise stacktrace of both threads involved in a race. However, for helgrind, the 'other thread' stacktrace is limited to 8 program counters (while the 'first thread' stacktrace is similarly limited by --num-callers=