Re: help on debugging individual extensions

[Sven Nielsen <post svennielsen de>]

Am 26.04.2012 20:32, schrieb Jasper St. Pierre:
> OK. So I talked this over with a bunch of coworkers, and we had a lot
> more ideas. (I've CC'd. Hopefully they can provide more insight than
> what I talked about here)
> 
>   * First of all, Valgrind. There are two tools in valgrind that are useful:
>      memcheck - The one that everybody knows. It should detect any
> leaks, but there are a lot of false positives.
>      massif - A heap profiler. It tracks every malloc by call stack
> and groups like ones together, to give you a rough idea of where
> memory is going. It may not work for JavaScript, as the call stack is
> going to be the same for all GObjects created through gjs (object_new
> => g_object_newv)
> 
>     Note that if you want to run Valgrind (or really any memory tool),
> make sure to set the G_SLICE and G_DEBUG env vars correctly. See the
> wiki page on Valgrind for more information[0].
> 
>   * JS has a heap profiler. You can see it in more recent Firefox
> builds at about:memory. This isn't in js185 AFAIK, so it's not
> available to us.
> 
>   * JS has another heap profiler, at JS_DumpTree. It's disabled by
> default in most builds (I don't know why). Can't use that.
> 
>   * SystemTap. We don't have SystemTap integration in the Shell yet
> (although you don't really need it as it can parse debuginfo, but it's
> more cumbersome). Here's an example SystemTap script from Colin that
> tracks GObject counts by type:
> 
>     https://bugzilla.gnome.org/show_bug.cgi?id=614619#c2
> 
> [0] http://live.gnome.org/Valgrind
> 

Thanks, Jasper! That looks promising. I will check it out and see if I
can successfully apply one of the mentioned tools.

Regards
Sven