> 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
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
