> Hi
> I have a Dtrace script ( attached ) which examines
> memory usage, using
> fbt:genunix:anon_resvmem:entry & return
> Seems to work well, tested with a small app that
> malloced < 65 K,
> malloced 200M and mmapeed a 16M file and it appeared
> to get things correct.
But is it tested with calls to free()?
> Basically I am looking at an app that seems to wander
> off the
> reservation in terms of memory usage, so wanted to
> rule out any bugs in the script.
AFAICT ::anon_unresvmem:entry/self->size > 0/ would never fire because
self->size is only non-zero during calls to anon_resvmem. That's probably why
there seems to be a memory leak.
> is there a way to get the stack of the calling app at the point in
> time of the anon_resvmem:entry & return.
ustack();
Other thoughts:
Most of those self-> variables (uid, pid, etc) seem unnecessary (though
harmless) because the values are just as easy to figure out from the :::return
as from the :::entry
Out of curiosity, why the test for non-NULL pr_psargs? Should unresvmem test
for it as well?
It seems like you'd want sth like this:
fbt:genunix:anon_resvmem:entry /arg1 != 0/
{ self->size = arg0; self->args = (char*) curpsinfo->pr_psargs; }
fbt:genunix:anon_resvmem:return /self->args != 0 && arg1 != 0/
{ printf(...); total[pid] += self->size; self->args = 0; }
fbt:genunix:anon_unresvmem:entry
{ self->size = arg0; self->args = (char*) curpsinfo->pr_psargs; }
fbt:genunix:anon_unresvmem:return /self->args != 0/
{ printf(...); total[pid] -= self->size; self->args = 0; }
Regards,
Ryan
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
