help with strange stack back trace

[Ramsés Morales <ramses computer org>]

Hi. 

I was going to debug a program with electric fence, using
EF_PROTECT_FREE=1 to detect access to freed memory. 

My program segfaults in a place it shouldn't, here is the backtrace: 

#0  0x404c9066 in strlen () from /lib/i686/libc.so.6 
#1  0x403f6ea8 in g_strdup () from /usr/local/lib/libglib-2.0.so.0 
#2  0x403ad2f9 in value_collect_string () at eval.c:41 
#3  0x401b2744 in gtk_tree_store_set_valist () at eval.c:41 
#4  0x401b293e in gtk_tree_store_set () at eval.c:41 
#5  0x0804a9ad in create_magazine_model () at main.c:563 
#6  0x08049f04 in create_app () at main.c:319 
#7  0x08049be1 in main (argc=1, argv=0xbffff9b4) at main.c:97 
#8  0x4045e627 in __libc_start_main (main=0x8049b80 <main>, argc=1, 
    ubp_av=0xbffff9b4, init=0x8049504 <_init>, fini=0x804bb20 <_fini>, 
    rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffff9ac) 
    at ../sysdeps/generic/libc-start.c:129 

This means that strlen() is working on a string previously freed. 

Obviously, this is the offending line of code (line: 285, gvaluetypes.c)

value->data[0].v_pointer = g_strdup (collect_values[0].v_pointer);

I'm not sure which one of the macros called inside
gtk_tree_store_set_valist is responsible for the value_collect_string.

This looks like a bug on gtk/glib.

Thanks for your help.