> I've made some progress on my program and now i would like to check > formemory leaks. Do you recommend any way or program in special for > doing this?
Something I've sometimes found useful, was to write a little chunk of code that throws up a small window that holds a list view, into which I place some basic information about various widgets and windows. Such things as address, visible state, name (if set), and the objets current reference count (which unfortunately can't be monitored with a signal handler). It won't find everything, but if you suspect an object might be hanging around, you can easily keep an eye on it. Essentially I wrote a add_XXX_watch() (eg. add_window_watch or add_object_watch) function which takes a newly allocated object, and connects a bunch of signals to it, along with a weak reference, and creates a row in the list view. (It also creates the list window if it's not already open) You just call that function in various places where you've created a new object. The class specific function connects callbacks that pluck out the information I'm interested in, forms it into a string, and sets that as the new row data (a simple string is nice and easy). One callback can usually handle several signals, by only taking the first argument (object pointer) and plucking out what it needs from scratch. When the weak reference ends, it alters the row colour, and sets the object pointer to NULL (so we don't go trying to access it). A quick row click handler lets me call gtk_window_present() on the entry clicked (doesn't work too good on non-windows though ;) ), and clicking an old reference (no object pointer) totally removes it from the list view. Generally I just toss little bits and pieces into the thing as I go along (or quite often, as I see them on this list and want to try it out for myself). It's a seriously messy piece of code, but it comes in quite handy. I actually practiced building my first menu popup on the thing. ;) The codes compiled as a small library I include into projects I'm working on, and the header makes everything go away nice and cleanly if a #define isn't jammed in. I think it's slowly evolving into some kind of gtk widget explorer, but one of its most handy features is still the reference count, of all things (which I update on a low priority timeout). The important thing, though, is that my little home-grown tool knows exactly what I'm often interested in, presents it in a way that I find appropriate, and provides me a means to quickly point my debugger at any of those objects, even if they're otherwise lost or a pain to track down from the present scope. (A couple function buttons in ddd let me do further poking around) It's another tool right alongside valgrind and debuggers. Fredderic _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
