|
From: Bill H. <ho...@cs...> - 2005-10-04 08:32:09
|
Using massif, I'm seeing the heap-admin band growing over time, but no other bands are. I'm not sure how my code could be causing a leak to be reported under heap-admin and only under heap-admin. Does anyone know how to interpret this behavior? A postscript plot generated by massif illustrating the behavior is here: http://cormorant.cs.pdx.edu/heapgrow.ps and the accompanying call graph is here: http://cormorant.cs.pdx.edu/heapgrow.txt I'm using STL with the deafult allocators, so some allocated memory won't be returned to the OS. However, the STL allocators should reuse previously allocated memory rather than continue to allocate more! Thanks for any help, Bill |
|
From: Josef W. <Jos...@gm...> - 2005-10-04 09:39:38
|
On Tuesday 04 October 2005 10:31, Bill Howe wrote: > Using massif, I'm seeing the heap-admin band growing over time, but no > other bands are. =A0I'm not sure how =A0my code could be causing a leak t= o be > reported under heap-admin and only under heap-admin. =A0Does anyone know = how > to interpret this behavior? malloc(0) ? Josef |
|
From: Nicholas N. <nj...@cs...> - 2005-10-04 14:14:55
|
On Tue, 4 Oct 2005, Josef Weidendorfer wrote: > On Tuesday 04 October 2005 10:31, Bill Howe wrote: >> Using massif, I'm seeing the heap-admin band growing over time, but no >> other bands are. =A0I'm not sure how =A0my code could be causing a leak = to be >> reported under heap-admin and only under heap-admin. =A0Does anyone know= how >> to interpret this behavior? Heap admin bytes are just computed as (n * number of heap blocks), where n= =20 defaults to 8 and can be changed with --heap-admin. > malloc(0) ? That's one possibility. Another is that the program is freeing a a few=20 large blocks and allocating more smaller ones, so the total amount of=20 asked-for memory is roughly constant but the number of blocks is growing. Nick |