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

[Ricardo Fernández Pascual <ric users sourceforge net>]

El dom, 11-08-2002 a las 20:13, Owen Taylor escribió:
> 
> 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.

You are right, it's easy in 90% of the cases. But sometimes I have
problems figuring it reading the code, and using memprof is easier than
going step by step in gdb.

> 
> 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_

This also worried me. My implementation uses really too much memory.

> 
>    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.

This could be done easily. The patch uses a hashtable of objects indexed
by their addresses. We could easily detect which blocks are objects
(looking if they are in the hashtable) and mark them somehow in the leak
report, allowing getting the ref/unref log using a context menu or
double clicking...

However, I like the separate view. But don't know if it is really useful
for the rest of the world.

>  - 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.

As far as I can tell, it still works with non-gnome programs and even
with gnome-1 programs. However, I'm not sure if it would work with
programs linked with different versions of glib (I mean future
versions).

It would be easy to disable these options at compile time. Don't know if
they could be disabled at runtime (any idea? maybe splitting the library
and setting the LD_PRELOAD differently in each case?).

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

Memprof is already very useful, even without the patch. Thanks for
writing it in the first place ;)

> Regards,
>                                         Owen

-- 
Ricardo Fernández Pascual
ric users sourceforge net
Murcia. España.

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers