|
From: Allyn D. <all...@gm...> - 2011-03-22 00:13:14
|
Hi, I am using helgrind to look for deadlocks in a C++ server program. I am running into the following problem: There are some objects that are declared statically in the server. I am seeing stack traces for "Required order" that include __static_initialization_and_destruction_0(...) in the stack trace. I am not interested in counter-examples that come from single-threaded portions of the server: some of the initialization code was written without regard for consistent lock ordering and I am not in a position to sanitize that code. Will having the server use something like VALGRIND_HG_CLEAN_MEMORY((char*)0, ~0)) clear the lock graph for me without nasty side effects? Actually, I know that the macro doesn't work with those particular arguments. It yields: > ==7592== Valgrind's memory management: out of memory: > ==7592== helgrind:shmem__bigchunk_alloc's request for 4194304 bytes failed. > ==7592== 3091869696 bytes have already been allocated. > ==7592== Valgrind cannot continue. Sorry. > = but I am not sure whether to refine the arguments or to try another route. Has someone solved this problem of reinitializing the lock order graph before? If so, please tell me your method: can the correct use of VALGRIND_HG_CLEAN_MEMORY do the job? Do I need to hack helgrind source code -- if so, an example would be most helpful. I don't recall seeing anything in the DRD or tsan documentation indicating that they report lock ordering problems, so I assume that helgrind is the proper tool for the job if I want to use dynamic analysis. Thanks, -- Allyn |