Re: [Fwd: Support for gobject tracking in memprof]

[Owen Taylor <otaylor redhat com>]

[ Cc'ing memprof list, since that exists now ]

Ricardo Fernández Pascual <ric users sourceforge net> writes:

>     I've been playing with memprof and added support for tracking
> GObjects (creation, ref, unref...). 
>     It keeps a list of all live gobjects of the program and tracks where
> every ref and unref is done. 
>     I have used it to find some leaks in galeon. I have tested it with
> several other programs and it seems to work correctly (btw: every gnome
> program leaves a lot of live GtkObjects when exiting, i guess this is
> intentional...). 
>     If people find this useful, I could clean the code and commit it to
> cvs. The patch is a bit dirty and has some code duplication because i
> didn't expect to get this working when I started it ;) 

Hi Ricardo,

Sorry for the delay in responding.

I guess my first reaction to the patch is: "Why isn't a GObject just
like any other allocated block of memory?" The refcount is not
particularly interesting for memprof, because it has something better
- it's leak detection facility.

Having the complete log of who ref'ed and unref'ed the object is
useful once you go from the stage of "this object was leaked" to "how
do we fix the leak of this object" could be useful ... but the fix
always seemed like the easy part to me.

So, I'm not completely opposed to the idea, but:

 - I'd like to get a better idea of how people would use
   this feature. I think there are a lot things we
   can do to memprof to improve the useability generally
   without special casing GObject.

   (Particularly: Improve the profile data based on the
   fact we do have full stack traces, and provide
   point to point memory usage diffs.)

 - We have to be careful about memory usage in MemProf.
   MemProf right now has the nice characteristic that it's 
   (excessive) memory usage is proportional to the amount of 
   allocated memory, not the amount of memory traffic.
   Some objects get ref'ed and unref'ed a _lot_

   I have some ideas about stack trace compression that 
   should help so that "ref'ed 100 times from X" 
  "unref'ed 99 times from Y" should be easy.

 - I think it should be a pretty unobstrusive part of the
   GUI ... in my opinion, if you have a block that is
   a GObject, perhaps you should be able to get a 
   refcount history, but I don't think it needs to 
   be a completely separate mode.

 - We have to make sure that any changes to memintercept.so
   didn't affect the ability to use memintercept.so with
   non-GNOME programs. An important goal of MemProf is
   to be able to handle non-GNOME programs.

Many thanks for the patch ... I think it's exciting that people are
looking at enhancing MemProf to be a better tool.

Regards,
                                        Owen