[ltt-dev] Segfault in state.c

Mathieu Desnoyers compudj at krystal.dyndns.org
Sat Oct 17 18:17:45 EDT 2009


* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> Excellent point.
> 
> Actually, looking back at state.c, I noticed there was a major problem
> with name table resizing:
> 
> the top level pointers were copied from the name table structure to the
> trace context, so when the tables were resized, the trace context was
> not updated and still refered to the old tables. This is why we could
> not free the old tables upon resizing.
> 
> It fixed all this in 1cd9058f63bc277629d796bac29c4530d151bea4.
> 
> Will be in the 0.12.18 release today.
> 

0.12.19 fixes a packaging issue present in 0.12.18. The headers were
left out of the Makefile.am for some reason. Probably due to the
refactoring done recently.

Thanks,

Mathieu

> Thanks,
> 
> Mathieu
> 
> * Nigel Hathaway (Nigel.Hathaway at ubiquisys.com) wrote:
> > In lttv/lttv/state.c, expand_trap_table() segfaults if the incoming
> > ts->nb_traps == 0 (with ts->trap_states == NULL, which actually causes
> > the segfault).
> > 
> > The version I have looks like this:
> > 
> > static void expand_trap_table(LttvTraceState *ts, int id)
> > {
> >   guint new_nb = check_expand(ts->nb_traps, id);
> >   guint i;
> >   if(likely(new_nb == ts->nb_traps))
> >     return;
> >   expand_name_table(ts, &ts->trap_names, ts->nb_traps, new_nb);
> >   fill_name_table(ts, ts->trap_names, ts->nb_traps, new_nb, "trap");
> >   /* Update the table size */
> >   ts->nb_traps = new_nb;
> > 
> >   LttvTrapState *old_table = ts->trap_states;
> >   ts->trap_states = g_new(LttvTrapState, new_nb);
> >   memcpy(ts->trap_states, old_table,
> >     ts->nb_traps * sizeof(LttvTrapState));
> >   for(i = ts->nb_traps; i < new_nb; i++)
> >     ts->trap_states[i].running = 0;
> > }
> > 
> > Also, the 'for' statement has no effect as it currently stands.
> > 
> > It would make more sense if the table size were updated at the end.
> > Doing this also fixes the segfault problem.
> > 
> > What happens to old_table if it is non-NULL? Isn't this a memory leak?
> > 
> > Here is the patch:
> > 
> > --- lttv-0.12.11-18022009.orig/lttv/lttv/state.c        2009-02-16
> > 01:41:18.000000000 +0000
> > +++ lttv-0.12.11-18022009/lttv/lttv/state.c     2009-10-08
> > 15:40:32.000000000 +0100
> > @@ -363,8 +363,6 @@
> >      return;
> >    expand_name_table(ts, &ts->trap_names, ts->nb_traps, new_nb);
> >    fill_name_table(ts, ts->trap_names, ts->nb_traps, new_nb, "trap");
> > -  /* Update the table size */
> > -  ts->nb_traps = new_nb;
> > 
> >    LttvTrapState *old_table = ts->trap_states;
> >    ts->trap_states = g_new(LttvTrapState, new_nb);
> > @@ -372,6 +370,9 @@
> >      ts->nb_traps * sizeof(LttvTrapState));
> >    for(i = ts->nb_traps; i < new_nb; i++)
> >      ts->trap_states[i].running = 0;
> > +
> > +  /* Update the table size */
> > +  ts->nb_traps = new_nb;
> >  }
> > 
> >  static void expand_irq_table(LttvTraceState *ts, int id)
> > 
> > 
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> > 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

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




More information about the lttng-dev mailing list