Brian, Brian Utterback wrote: > I have a program that is leaking memory. I am using libumem > to help diagnose the problem, but I have a couple of problems. > > The program has been running for about 2 months, and is > now 1168M in size, with a RSS of 984M. The output of pmap shows > that almost all of that is in the heap: > > 0807A000 1193960 1006512 1006220 - rw--- [ heap ] > > When I run ::findleaks, I get this: > > >> ::findleaks > > BYTES LEAKED VMEM_SEG CALLER > 42056-2134736 17 82b5ca8 input_route+0x15e > ------------------------------------------------------------------------ > Total 17 oversized leaks, 20204056 bytes > > CACHE LEAKED BUFCTL CALLER > 0809e810 1 0812a330 input_route+0x15e > 0809ec10 1 080e6c38 input_route+0x15e > 08098810 15193 080c3a58 rtmalloc+0xe > 08098810 1 0a3acb20 rtmalloc+0xe > 08098810 1 080c3968 rtmalloc+0xe > 08098810 1 080c3878 rtmalloc+0xe > 08098810 38 080cb208 rtmalloc+0xe > ---------------------------------------------------------------------- > Total 15236 buffers, 1222112 bytes >
take the address below BUFCTL and run <addr>::bufctl -v to see the stack for that particular leak or actually on how that memory was allcoated. Now you need to see where it wasn't deallocated/freed to find the leak. if the system is running bits with 6266121 included, you can check the history with "bufctl -hv" option. man page of umem_debug(3MALLOC) is usually helpful on how to use libumem. HTH, Raja > I am not entirely sure what that first part is telling me, but the > LEAKED value of 17 doesn't seem to change. On the other hand, the > number of leaks in the second section is continually increasing. But > is I run umausers, I get: > > > ::umausers > 1215840 bytes for 15198 allocations with data size 80: > libumem.so.1`umem_cache_alloc_debug+0x16c > libumem.so.1`umem_cache_alloc+0x15c > libumem.so.1`umem_alloc+0x3f > libumem.so.1`malloc+0x23 > rtmalloc+0xe > rtadd+0x43 > ifscan+0x12e4 > main+0x81e > _start+0x7a > > So, a couple of questions come to mind. One, am I even on the right > track here? If the data allocation size is 80 bytes, even 15198 leaks > would only account for a meg of data. Even if each 80 bytes lived on > its own 4K page, that would still only be 64 MB. Second, you'll notice > that there are 5 eighty byte allocations from that location that are > not leaked. Is there anyway to tell if it is the same 5 buffers, or > if it is always the last 5 buffers, or what? In other words, can I > get the addresses of the 5 unleaked buffers? > > I wish there was a little more complete info on how to use libumem. The > docs are a bit spotty. What info I can find is always of the nature > "Hey, did you know that libumem can do this?" > > Thanks in advance for any help. > -- Raja Gopal Andra Sun Microsystems Phone: +1 650 786 4273 Solaris RPE 17 Network Circle, Fax : +1 650 786 7994 Approachability Group Menlo Park, CA 94025 mailto: andra at sun.com -- The secret to success is to work less as individuals and more as a team.
