|
> 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 gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
