HI Philippe,
I read valgrind user manual, there are some hints which are related to my
problem I guess. As follows,
Myprog uses tons of mmap and memory pool ,and do not use free/delete to give
back memory to pool.
My question is that If mypog use memoy pool without free/delete and don't use
VALGRIND_HG_CLEAN_MEMORY will lead to myprog do mmap endlessly until use 64G
memory?
--------------------------------
Avoid memory recycling. If you can??t avoid it, you must use tell Helgrind what
is going on via the
VALGRIND_HG_CLEAN_MEMORY client request (in helgrind.h).
Helgrind is aware of standard heap memory allocation and deallocation that
occurs via malloc/free/new/delete
and from entry and exit of stack frames. In particular, when memory is
deallocated via free, delete, or
function exit, Helgrind considers that memory clean, so when it is eventually
reallocated, its history is irrelevant.
However, it is common practice to implement memory recycling schemes. In these,
memory to be freed is not
handed to free/delete, but instead put into a pool of free buffers to be handed
out again as required. The
problem is that Helgrind has no way to know that such memory is logically no
longer in use, and its history is
irrelevant. Hence you must make that explicit, using the
VALGRIND_HG_CLEAN_MEMORY client request to
specify the relevant address ranges. It??s easiest to put these requests into
the pool manager code, and use them either when memory is returned to the pool,
or is allocated from it.
---------------------------
> --28682-- univ_laog_do_GC enter cardinality 9614
> --28682-- univ_laog_do_GC exit seen 6591 next gc at cardinality 9615
yes, one of the things that --stats=yes activates is some information
about laog GC.
>
> why?
> DRD have not that problem ,but DRD 's message is not accurate
> comparing with helgrind.
helgrind data structures are different of drd (a.o. to be able
to give precise information about race conditios).
Normally, --stats=yes should have produced statistics
at the end of your program (if your program exited due to
out of memory). If valgrind itself encountered the oom situation
then it should equally have produced statistics.
Can you post here these statistics ?
If they are not produced (unclear why), then you could instead
regularly run in another window
vgdb -c v.info stats -c v.info memory
to capture stats/memory during the run, before it reaches 64G.
Philippe------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
