Thanks to Paul and Justin for the advice offered on this thread.
[snip]
>> You can also do things like take a coredump (gcore) and run dbx/mdb
> on /that/ (useful for when you cant replicate the leak, but your
> customer can ;) - just ask them to set the relevant libumem
> environment variable and then 'gcore' the process once the leak is
> established and send you the core.)
>> mdb is really good, but a bit cryptic and alien initially if you're
> used to gdb though.
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 ?
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. 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.
Are there any other internet references to documentation apart from
http://docs.sun.com/app/docs/doc/816-5041/6mb7ae3ja?a=view
Cheers,
Sean
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
