Purifying Mozilla on Solaris
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 220.127.116.11 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.
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
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"
Bruce Mitchner (Mr. Purify) for the tips and tricks
Brian Stell for the bsh info