<div class="gmail_extra">On Sat, Dec 8, 2012 at 11:18 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":zy">On Dec 8, 2012, at 12:13 PM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> Sounds good to me.<br>
<br>
   Note if we somehow specially mark a malloc in the creation of PetscHeader we may not even need to have a separate data structure for keeping track of object mallocs. Just have a special PetscMallocDump() type of function that only prints the stacks for each new object (and not for every malloc).</div>
</blockquote></div><br>Okay, so add a field to TRSPACE to record object class, then have PetscLogObjCreateDefault() call a PetscTrMallocSetClass(void *malloced_addr,PetscTrMallocClass traceclass) to change the tracing class of an existing piece of memory (the implementation can walk the tables to find the memory, though in the common case, it will already be at head). Then we add support for "-malloc_dump_class mat,ksp" (no argument means trace all objects).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Sensible or overkill?</div>