Looking For

Purifying Mozilla on Solaris

Seth Spitzer

post comments / questions to news://news.mozilla.org/netscape.public.mozilla.unix

9/8/01 : gcc 2.95.3 has been found to work with purify 2002.05.00.Proto.0010, so we are supposedly no longer stuck with the old 2.7.2.3 compiler. -mcafee
step 1: build mozilla on solaris
if that is a problem, you got bigger fish to fry

step 2: build the purify version of mozilla
$ setenv PURIFYOPTIONS -best-effort
$ cd mozilla/xpfe/bootstrap
$ gmake CXX=g++ pure

step 3: run the purify version
# I needed to up the limit on open file descriptors, or I'd run out when
# trying to purify Mozilla.
# if you use csh / tcsh, do this:

$ limit descriptors 1024

# if you use bsh, do this:

$ ulimit -n 1024

$ cd mozilla/dist/bin
$ ./mozilla -pure

Tips and Tricks
# you may want to add these to your ~/.purify file
suppress bsw *
suppress umr _write; write
suppress umr memcmp; LocalConnection; XShmQueryVersion
suppress umr gdk_rgb_try_colormap
suppress umr gdk_color_hash
suppress umr gtk_widget_set_sensitive
suppress umr HandleComposeSequence; _XTranslateKeySym; XLookupString; _MbLookupString; XmbLookupString
suppress abr miSubtractO; miRegionOp; XSubtractRegion; gdk_regions_subtract
suppress umr XListFonts; GetFontNames(char*)
suppress umr __sigprocmask; _thrp_exit; _thr_exit_common; _age; _door_return
suppress fmr XDestroyIC; gdk_ic_destroy; gtk_entry_unrealize
suppress fum free; gdk_ic_destroy; gtk_entry_unrealize
suppress bsw pthread_mutex_unlock

# memory in use 
Purify has a nice preference to have it record memory in use at the time
of the exit of the application.

# BSWs
The BSWs only start showing up after you install some patches on Solaris
2.6.  I think they started showing up for me when I'd had some patches
installed for green threads for Java.

# New leaks
You can have it check for new leaks from the Purify menu.  This rocks.
You can do something in the UI and immediately check for new leaks.
Unfortunately, I don't think it'll show the difference in what is still in
use, so you can't see how much bloat doing something might have (to the
best of my knowledge).

# Potential leaks.
PLK (potential leaks) are real problems, not just 'potential'
problems.  This is due to how QueryInterface stuff works with COM.  Read
the manual to have this made clear.

# Xlib & gcc problems
From bstell@netscape.com:

 I had trouble compiling as Xlib and the current gcc
 are "out of sync" and gcc burps on Xlib's prototypes.

 I found this workaround:

 # workaround (for bsh) since gcc/g++ and Xlib are out of sync
 export CFLAGS="-isystem /usr/openwin/include"
 export CXXFLAGS="-isystem /usr/openwin/include"

Thanks

Bruce Mitchner (Mr. Purify) for the tips and tricks
Brian Stell for the bsh info