Eric Schrock wrote: > Are you sure you had UMEM_DEBUG set in your environment? Just linking > to libumem doesn't enable the debugging flags. What does > '::getenv -t', '::umem_status', and 'umem_flags/X' show? >
Yeah, that was my thought that they did not set the environment up correctly, and I have asked about this. I will look into your commands and see what they report. As an aside, which I may not have made clear, other callers and stacks are reported data correctly. I just snipped that data. peter > - Eric > > On Tue, Oct 23, 2007 at 03:48:22PM -0400, Peter Shoults wrote: > >> Hi, >> >> I am troubleshooting a memory leak issue and have captured a gcore from >> a running process with libumem enabled. It reports something I have >> never seen before, and that I could not find any information about. >> Here is what findleaks -d reports: >> >> > ::findleaks -d >> CACHE LEAKED BUFCTL CALLER >> (SNIP) >> 0000000101208de8 585 000000010123c3a0 0 >> (SNIP) >> >> umem_alloc_64 leak: 585 buffers, 64 bytes each, 37440 bytes total >> ADDR BUFADDR TIMESTAMP THREAD >> CACHE LASTLOG CONTENTS >> 10123c3a0 10123b080 71236ea2aea11 1 >> 101208de8 0 0 >> >> Can anyone explain why I am not getting any printed caller or stack output? >> >> Peter >> _______________________________________________ >> mdb-discuss mailing list >> mdb-discuss at opensolaris.org >> > > -- > Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock >
