Hi Philippe,
>The best way to understand where valgrind/helgrind spends
>memory is to use --stats=yes and post the result here.
>Really, it is really the best way :).
>If it takes too long to reach the end (or it crashes
>before producing the stats),
>you can from the command line use
> vgdb v.info stats
>to get the needed info while helgrind is running.
I can not post log directly, I copy it and write here.as follows:
use --stats=yes valgrind 3.10.1
......
--8146--libhb:EvM GC?? delete generations 129 and below, retaining 505211
entries
--8146--libhb:EvM GC?? delete generations 139 and below, retaining 526605
entries
--8146--libhb:EvM GC?? delete generations 149 and below, retaining 520572
entries
--8146--libhb:EvM GC?? delete generations 159 and below, retaining 504065
entries
--8146-- univ_laog_do_GC enter cardinality 31
--8146-- univ_laog_do_GC exit seen 24 next gc at cardinality 32
--8146-- univ_laog_do_GC enter cardinality 33
--8146-- univ_laog_do_GC exit seen 30 next gc at cardinality 33
....
--8146-- univ_laog_do_GC enter cardinality 61779
--8146-- univ_laog_do_GC exit seen 41326 next gc at cardinality 61780
--8146-- univ_laog_do_GC enter cardinality 61780
--8146-- VALGRIND INTERNAL ERROR:Valgrind received a signal 11 (SIGSEGV)
-exiting
--8146-- si_code = 1; Faulting address:0x8031AD000; sp: 0x80317db70
valgrind :the 'impossible' happened:
Killed by fatal signal
host stacktrace:
==8146== at 0x3802D180:reclaimSuperblock(m_mallocfree.c:918)
==8146== by 0x3802F2D0:deferred_reclaimSuperblock(m_mallocfree.c:1939)
==8146== by 0x3800CA22:delete_WV (hg_wordset.c:204)
==8146== by 0x3800EC54:vgHelgrind_dieWS(hg_wordset.c:487)
==8146== by 0x38005816:univ_laog_do_GC(hg_main.c:3454)
HI Philippe,
??memory is to use --stats=yes and post the result here.
>Really, it is really the best way :).
I can not export log from my PC, because PC is isolated from internet.
Can I take a photo of log to you or Can pick up some key information from log
to you.
By the way, the size of email is limited to 40KB, am I right? so posting a
photo maybe not work out.
> 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?
No, HG_CLEAN_MEMORY is not useful to use less memory.
It is only useful if you recycle memory, and you get
false positive race errors due to this recycling.
The best way to understand where valgrind/helgrind spends
memory is to use --stats=yes and post the result here.
Really, it is really the best way :).
If it takes too long to reach the end (or it crashes
before producing the stats),
you can from the command line use
vgdb v.info stats
to get the needed info while helgrind is running.
Philippe
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
