for analyzing leaks, reporting the count of allocations from that callstack
and the ordinals of the ones that leaked would be useful
then you'd know "ok it's the 53rd instance here that leaked, so it's on
some rare path, and from the timetamp (PR 465163) it happened late in the
run"
this case includes adding the timestamp to leaks that was added to other errors in
PR 465163. we'll have to add it to all stored callstacks which will occupy
some space, so we may want it under a runtime option
From derek.br...@gmail.com on December 10, 2010 17:58:15
PR 514043
for analyzing leaks, reporting the count of allocations from that callstack and the ordinals of the ones that leaked would be useful
then you'd know "ok it's the 53rd instance here that leaked, so it's on some rare path, and from the timetamp (PR 465163) it happened late in the run"
this case includes adding the timestamp to leaks that was added to other errors in PR 465163. we'll have to add it to all stored callstacks which will occupy some space, so we may want it under a runtime option
Original issue: http://code.google.com/p/drmemory/issues/detail?id=173