Re: help on debugging individual extensions

["Jasper St. Pierre" <jstpierre mecheye net>]

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

On Thu, Apr 26, 2012 at 3:17 AM, Sven Nielsen <post svennielsen de> wrote:
>>> So, I was hoping some dev here might be able to give me some definite
>>> hint, like:
>>>
>>> enable these debug packages, start debugging with these flags, and then
>>> watch this and that log for, let's say, for instance, memory consumption
>>> of variables/classes etc. of individual objects/classes in the shell
>>> therads. Something in that direction, which is understandable for a tech
>>> user like me, you see?
>>
>> There is some experimental SystemTap support, but it's nowhere near ready.
>> Something you can do: paste the numbers from the memory tab in the
>> looking glass. Hit the "full GC" button as well. What do you see?
>>
>
> Well, I see copy and paste support missing in lg...
>
> and I see glibc_uordblks rising with every click on Full GC, and I see
> "js bytes" memory gradually and slowly rising, which gives me no more
> information than htop before.
>
> I already disabled the (assumingly) badly written "Deepin Enhanced Dock"
> extension, and memory rises more slowly already, but, e.g., in the last
> 1,5 hrs resource memory in htop, again, rose from 170MB to 218MB. Still,
> that's all no way nearer to actually chasing any specific leaks..
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list



-- 
  Jasper