Dan McDonald <[EMAIL PROTECTED]> writes: > It's not dtrace-related, but you should check out the following: > > On Wed, Nov 07, 2007 at 01:45:33PM -0500, Pierre-Olivier Gaillard wrote: >> I am investigating a memory problem (access to memory that was >> released previously) that Purify can't analyze. >> >> As I don't know the program I am analyzing, I thought I could >> generate a big trace of all function calls and search through it. > > Have you tried libumem? It's frickin' awesome for catching problems > like this (and part of OpenSolaris for free)! > > Run your program like so (assuming sh,ksh,bash): > > LD_PRELOAD=libumem.so UMEM_DEBUG=default <your-program> > > or with csh,tcsh: > > ( setenv LD_PRELOAD libumem.so; setenv UMEM_DEBUG default ; > <your-program>) > > And watch libumem catch your program in the act! It will dump core, > and you can use MDB's post-mortem UMEM analysis tools like > "::findleaks" and "::bufctl". > > There's got to be a page with examples, I just don't have it off the > top of my head.
Here's one: http://blogs.sun.com/pnayak/entry/finding_memory_leaks_within_solaris And a list of others: http://www.genunix.org/wiki/index.php/libumem_Resources Boyd _______________________________________________ dtrace-discuss mailing list [email protected]
