|
From: Nicholas N. <nj...@cs...> - 2005-12-06 17:41:43
|
Hi, Here's an interesting experiment. Run 'top', hitting space frequently. Note that the SIZE field of 'top' itself stays constant (for me it's 1068k). Now run "valgrind --tool=none top". The SIZE field of 'none' grows briefly at the start, then stays constant. The same is true of Cachegrind. Massif grows very slowly as it takes more heap censuses. Now try it with Memcheck. Whoa! That looks like a memory leak. Anyone feeling bored? Nick |
|
From: Julian S. <js...@ac...> - 2005-12-06 22:25:32
|
I ran it for 3 cpu minutes (set update interval to 0.3s, let it grind away) and it did slowly edge up through 42M Virtual. I'd guess this is the freed blocks queue slowly filling up, particularly as top is evidently turning over memory at a modest rate: ==29838== malloc/free: in use at exit: 66,287 bytes in 119 blocks. ==29838== malloc/free: 1,763 allocs, 1,644 frees, 1,257,443 bytes allocated. If the same thing happens with --freelist-vol=0 then it maybe really is a leak. J On Tuesday 06 December 2005 17:41, Nicholas Nethercote wrote: > Hi, > > Here's an interesting experiment. Run 'top', hitting space frequently. > Note that the SIZE field of 'top' itself stays constant (for me it's > 1068k). > > Now run "valgrind --tool=none top". The SIZE field of 'none' grows > briefly at the start, then stays constant. The same is true of > Cachegrind. Massif grows very slowly as it takes more heap censuses. > > Now try it with Memcheck. Whoa! That looks like a memory leak. Anyone > feeling bored? > > Nick > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@cs...> - 2005-12-19 19:57:33
|
On Tue, 6 Dec 2005, Julian Seward wrote: > I ran it for 3 cpu minutes (set update interval to 0.3s, let it > grind away) and it did slowly edge up through 42M Virtual. > I'd guess this is the freed blocks queue slowly filling up, > particularly as top is evidently turning over memory at a > modest rate: > > ==29838== malloc/free: in use at exit: 66,287 bytes in 119 blocks. > ==29838== malloc/free: 1,763 allocs, 1,644 frees, 1,257,443 bytes allocated. > > If the same thing happens with --freelist-vol=0 then it maybe > really is a leak. With --freelist-vol=0 it doesn't grow at all. So definitely a false alarm. Nick |