[ltt-dev] issues with lttv 0.12.7

[Josh Boyer]

On Wed, Jul 01, 2009 at 05:12:00PM -0400, Mathieu Desnoyers wrote:
>* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
>> * Dany Madden (dany.r.madden at gmail.com) wrote:
>> > Hi Mathieu,
>> > 
>> > As you suggested, I've tested <lttv --memory -m textDump -t /tmp/trace1>
>> > command with glib 2.21.2 and lttv-0.12.16-19062009. I still see the same
>> > segfault and bt. Any more suggestions? :)
>> > 
>> 
>> ./configure CFLAGS=-g && make && make install
>> 
>> gdb lttv.real
>> (gdb) set args --debug -v --fatal --memory -m textDump -t /tmp/trace
>> ...
>> bt full
>> 
>> should provide useful output.. but it looks like there is something
>> wrong with the glib memory profiler due to our extensive use of the
>> gquarks. Maybe we overflow one of its tables...
>> 
>> One thing to try would be to allocate the strings ourself elsewhere and
>> use g_quark_from_static_string. It seems particularly important in
>> ltt/marker.c, where we generate a quark for each channel, event and
>> field name. refs :
>> 
>> http://library.gnome.org/devel/glib/unstable/glib-Memory-Allocation.html
>> http://library.gnome.org/devel/glib/unstable/glib-Quarks.html
>> 
>
>OK, what we get is :
>
>(process:12835): GLib-WARNING **: realloc(0x631710, 8192): memory has
>been freed 7566456 times already
>
>If I run it with --fatal, I see that a g_quark_from_string is causing
>this warning. It looks like the GQuarks are therefore reallocating their
>string table quite often.
>
>Now removing --fatal lets the execution continue until we get :
>
>
>GLib Memory statistics (successful operations):
> blocks of | allocated  | freed      | allocated  | freed      | n_bytes   
>  n_bytes  | n_times by | n_times by | n_times by | n_times by | remaining 
>           | malloc()   | free()     | realloc()  | realloc()  |           
>===========|============|============|============|============|===========
>         1 |         11 |          2 |          0 |          0 |         +9
>...
>      4088 |          0 |          0 |          1 |          0 |      +4088
>   >  4096 |          1 |          0 |         44 |          0 |        ***
>GLib Memory statistics (failing operations):
> blocks of | allocated  | freed      | allocated  | freed      | n_bytes   
>  n_bytes  | n_times by | n_times by | n_times by | n_times by | remaining 
>           | malloc()   | free()     | realloc()  | realloc()  |           
>===========|============|============|============|============|===========
>   >  4096 |          0 |          0 |          1 |          0 |        ***
>Total bytes: allocated=969592, zero-initialized=20380 (2.10%), freed=640269 (66.03%), remaining=329323
>
>GLib-ERROR **: /tmp/buildd/glib2.0-2.16.3/glib/gmem.c:175: failed to allocate 8192 bytes
>aborting...
>
>So it looks like the allocator profiler refuses to allocate a 8kB memory
>region. Looking at the table above, I notice that it stops at 4k...
>something really looks fishy in the glib profiler... ;)

I am going to ask what is probably a stupid question.  However, I am confused
so I'll ask it anyway.

What is the --memory option actually supposed to do?

The --help output just says "print memory information".  When I look at the
code for the --memory option, and the glib APIs it calls, it seems that all it
is doing is hooking a glib memory profiler up to track memory usage of lttv
itself.  It does not appear to have anything to do with the other options
you're passing to lttv, e.g. it's not printing memory information about the
trace you just collected.

Is that assessment correct?  If so, I might have to send a patch to make the
--help output for the --memory option be a little more verbose.

josh