[ILUG] [OT] Looking for recommendations for solaris memory checker

[Paul Jakma]

On Thu, 5 May 2005, Sean Ryan wrote:

> Looks like mdb / libumem is the way to go.  Unfortunately one of 
> the environments is Solaris 8 on a SunFire on a sparc arch.  Is 
> libumem available on a Solaris 8 ?

It was introduced with Solaris 9 iirc. So I dont think it will be 
available on that S8 machine (the hardware doesnt matter btw ;) ). 
However, any leaks you can catch and fix by debugging on S9+ machines 
will work for your application running on the S8 machine, obviously. 
;)

I'd reccomend using -lumem by default on S9 and up. It's better than 
the stock libc malloc.

> Seeing as I already have numerous core files (produced from both 
> gcore and good-old fashioned application falling over) - mdb 
> examination of the process is the obvious step forward.

The core's wont contain any umem leak-debugging information unless:

1. The application was linked to libumem
    (at 'build' time, or runtime via LD_PRELOAD)

2. Allocation tracking was enabled at runtime via the appropriate
    environment variables, see man umem_debug

> Having already examined the cores with gdb I can identify the 
> offending thread but not having any real success identifying the 
> source of the leak.

The following is what you want (if your app is not linked to 
libumem already):

# UMEM_DEBUG=default UMEM_LOGGING=transaction \
> LD_PRELOAD=/usr/lib/libumem.so /path/to/my/app

<let it run and leak, gcore it, open 'mdb' with the core file>

> ::find_leaks

( > is the mdb prompt)

> Are there any other internet references to documentation apart from
> http://docs.sun.com/app/docs/doc/816-5041/6mb7ae3ja?a=view

man mdb? And in mdb, type ::help.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
phosflink:
 	To flick a bulb on and off when it burns out (as if, somehow, that
 	will bring it back to life).
 		-- "Sniglets", Rich Hall & Friends