Re: [Valgrind-users] [PATCH] two more mempool client requests, plus sanity checks and logging

[Julian S. <js...@ac...>]

Looks fine.  The only problem I can see is that you #included
coregrind/pub_core_options.h into memcheck/mc_malloc_wrappers.c,
which totally breaks the core/tool abstraction :-)  Tools are
only allowed to include pub_tool_*.h.

But AFAICS it's only to provide debugging printing (for the mempools
machinery itself) at -v -v and above.  So how about if I just hardwire 
a fixed backtrace depth, say 16, in place of those uses of 
VG_(clo_backtrace_size) ?

J


On Saturday 09 September 2006 00:43, Graydon Hoare wrote:
> Here's an update to the mempool move / change client requests and sanity
> checking. The following changes are present:
>
>    - Added one more (hopefully last) client request, a predicate to
>      test whether a mempool anchor address is currently tracked.
>      It turns out mozilla's arena-using code is sufficiently inconsistent
>      in its assumptions that it's very difficult to phrase the valgrind
>      client-request annotations without this request. Namely: sometime
>      arena-init and arena-free operations are assumed to be idempotent.
>
>    - Fixed a very rapid tool-memory leak in the mempool sanity check
>      routine. The previous version of the patch I posted would use all
>      memory even on my Very Beefy Test Machine within ~15 minutes of
>      browsing with firefox.
>
>    - Added a little logging code to print the counts of pools and chunks
>      active every ~10000 sanity checks, when running with -v.
>
> You'll also need to tack on this paragraph to the suggested mempool
> client-request documentation I posted:
>
> VALGRIND_MEMPOOL_EXISTS(pool)
>
> This request informs the caller whether or not memcheck is currently
> tracking a mempool at anchor address "pool". It evaluates to 1 when
> there is a mempool associated with that address, 0 otherwise. This is a
> rare request, only useful in circumstances when client code might have
> lost track of the set of active mempools.
>
> Thanks,
>
> -graydon