[ltt-dev] issues with lttv 0.12.7

[Mathieu Desnoyers]

* Josh Boyer (jwboyer at linux.vnet.ibm.com) wrote:
> 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.
> 

Yep, that's internal lttv introspection. It has nothing to do with the
trace looked at.

Mathieu

> josh
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68