|
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
|