|
From: Brian M. <bm...@ar...> - 2004-05-10 18:50:15
|
Hello, Is there any way to suppress the tracking of particular allocations while running my app with massif? We have the situation that we are tracking the memory usage of a algorithmic process and are not concerned with certain allocations within our app as they are not counted against our memory budget. Is there any way using a suppression file or other approach that massif will exclude/ignore allocations that we specify as insignificant? I'm using the current cvs version of valgrind/massif and looking at the code, there was no obvious way to do this. Using the --alloc-fn switch is not exactly what we need, since those allocations are still accounted for as part of the overall picture, which is what we're trying to avoid. I am willing to take a crack at making some mods myself, but I am looking for pointers so that I don't inadvertently mess up key internal housekeeping data or otherwise throw off my results in strange ways. thanks in advance, --Brian Mosher |
|
From: Nicholas N. <nj...@ca...> - 2004-05-10 20:59:17
|
On Mon, 10 May 2004, Brian Mosher wrote: > Is there any way to suppress the tracking of particular allocations while > running my app with massif? > > We have the situation that we are tracking the memory usage of a > algorithmic process and are not concerned with certain allocations within > our app as they are not counted against our memory budget. Is there any > way using a suppression file or other approach that massif will > exclude/ignore allocations that we specify as insignificant? I'm using the > current cvs version of valgrind/massif and looking at the code, there was > no obvious way to do this. Using the --alloc-fn switch is not exactly what > we need, since those allocations are still accounted for as part of the > overall picture, which is what we're trying to avoid. There's no way to do what you are describing. > I am willing to take a crack at making some mods myself, but I am looking > for pointers so that I don't inadvertently mess up key internal > housekeeping data or otherwise throw off my results in strange ways. Shouldn't be too hard. I would edit get_XCon() -- after the stack snapshot has been successfully taken, look at the eip[] array and decide if you want to ignore this allocation. If so, don't insert the XCon into the tree. You'll probably also have to change die_block() so that it can cope with there being no XCon for these blocks when they're freed. HTH N |