> BTW, if anyone has a better way of tracing memleaks in glib/gtk based apps, > without valgrind or using it in another way, steps are welcome!
Here is some info on purify that someone may find useful: I have been using Purify for a few years to test gtk apps. Purify also gets very confused by some of the gtk memory management techniques, and reports many errors. I created a simple gtk app that uses all the widgets and functions that we use across our many GUIs. I ran that app with purify, and created a suppression file to suppress all of the reported errors from this simple app. I use that same suppression file when running the production GUIs, so I only see errors coming from mistakes in our GUI code. This method may not catch all true leaks because our code may be triggering a memory allocation that gets suppressed, and our code may neglect to trigger the free or dereference. So, I usually take a second step by monitoring the memory usage of the GUIs over an extended period of time. Another problem I've had with purify is that it fails to instrument against an optimized gtk build. So, I have to instrument against a debug build of gtk. This is a known purify bug. -Anthony Vallone
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
