|
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 |
|
From: Julian S. <js...@ac...> - 2011-03-22 16:21:14
|
> 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.
Er, yeh. That doesn't surprise me :-)
What you ask seems like a reasonable question, but AFAIK there's no
way to do it. The obvious thing would be to introduce a new client
request that asks the lock acquisition order graph ("laog", in the
sources) machinery to forget everything.
Plumbing in the client requests isn't hard, just follow the trail
of breadcrumbs starting at (eg) VALGRIND_HG_CLEAN_MEMORY, and make
your own, eg VALGRIND_HG_REINITIALISE_LOCKGRAPH (or whatever name
you think suitable).
More tricky is nuking the laog datastructures themselves. It's
probably easy; I just don't remember much about it. Place to look
is in hg_main.c.
btw, valgrind trunk has significant helgrind perf improvements and
space reduction compared to 3.6.1. And branches/HGDEV2 contains
more improvements -- better error messages and further space usage
reductions.
If you hack up a patch and it solves your problem, pls file a bug
and attach the patch to the bug.
J
|