On Wed, 2015-06-17 at 20:25 +0800, 王阳 wrote: > >Before fixing the above, what you can do then is to capture > >the statistics before it crashes, using from a shell: > > vgdb v.info stats > >and post the resulting output > >(do the above when your application has already consumed a > significant > >memory, but before it has crashed :). > I take it when myprog under valgrind used 29.2GB memory, I guess it is > significant enough. Yes, this is for sure ok.
> Wordset "univ_laog": > addTo 240996259(240994769 uncached) > delForm 10 (10 uncached) This (and the LAOG exposition size) below is a possible candidate for the big memory use. Can you try to run with --track-lockorders=no so as to disable the LAOG algorithm ? > union 0 > intersect 0 (0 uncahed ) [nb .incl isSubsetof] > minus 0 > elem 0 > doubleton 15559 > isEmpty 0 > isSingleton 0 > anyElementOf 0 > isSubsetof 0 > dieWS 240966779 > > > locksets: 15,615 unique lock sets > univ_laog: 46,445 unique lock sets > LockN-to-P map: 1 queries(1 map size) > string table map: 0 queries(0 map size) > LAOG:15.557 map size > LAOG exposition: 120,505,100 map size This LAOG exposition seems huge. > locks: 931,132 acquires, 915,607 releases > sanity checks: > > > <<<BEGIN libhb stats>>> > secmaps: 66,706 allocd (546,455,552 g-a-range) this means that your own memory allocation is not huge (slightly more than 0.5GB). > If --track-lockorders=no does not solve the problem, can you then re-run with --stats=yes --profile-heap=yes and while it runs (and has consumed already significant memory), do vgdb -c v.info stats -c v.info memory aspacemgr and post the result ? Thanks Philippe ------------------------------------------------------------------------------ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
