Alan Hargreaves' Weblog

The ramblings of an Australian SaND TSC* Principal Field Technologist

* Solaris and Network Domain Technology Support Centre - The group I work for

Tags

(update 1) acoustic bind birthday blues bugs cec cec2007 cec2008 china cmt contention cringley debugging dogs dtrace earthquake encumbered-binaries extra flash funny google guitar halloween huron install kids linux liveupgrade locking mdb music mysql newyear niagra openjava opensolaris oracle patches patents percussion performance redhat secondlife security solaris sru sun support sxcr t2 t2000 timeslider ufs upgrade virtualbox windows youtube zfs
« Previous day (Jun 12, 2004) | Main | Next day (Jun 14, 2004) »
pageicon Monday Jun 14, 2004

More on Finding leaks in application space

The document I referenced is now available on sunsolve as 76774

There are a few typos that needed fixing in there that have now been fixed. We are just waiting for the final review to replace the currently published document.

There was a comment about getting Sun to help out the folks at the Mozilla Foundation. These comments have been passed on and have flagged an interesting discussion about possibilities.

The response that I got after publishing that blog entry shows just how useful this can be as a medium for getting information out. Hopefully it's one we can keep positive and worthwhile.

On a similar vein, as I referenced a document on sunsolve, we would appreciate any feedback that anyone wanted to give on it's usefulness (see my prior entry on sunsolve). That being said, we appreciate feedback on pretty much everything that we push out to sunsolve.

Update

Looking back on what I wrote previously it may not be very clear the path that I took to detetmine that the source of the leaks was inside particular modules. Well, it wasn't really that difficult. The trick being that if we get the stack from the ::bufctl_audit command inside mdb, we get a list of the stack return addresses. Now all we have to do to find which module it is from is to look at the memory map of the core file from with mdb. This is done with $m. In the case of one of the leaks that I looked at, the address was 0xfce7ac40. Taking an excerpt of the $m output we see that this is... 

> $m
    BASE    LIMIT     SIZE NAME
   10000    52000    42000 /tmp/mozilla/mozilla-bin
   60000    64000     4000 /tmp/mozilla/mozilla-bin
   64000 1112e000 110ca000 /tmp/mozilla/mozilla-bin
   ...
fce00000 fceda000    da000 /tmp/mozilla/components/libmsgimap.so
   ...

and hence in libmsgimap.so

Posted at 06:01PM Jun 14, 2004 by Alan Hargreaves in General  |  Comments[1]