Re: Window destroy = program crash?

[Owen Taylor <otaylor redhat com>]

"David J. Topper" <topper virginia edu> writes:

> Owen Taylor wrote:
> 
> > Segfault in free == memory corruption somewhere else in
> > your app. It's most likely a double free - to catch that
> > on Linux, try:
> >
> >  $ gdb myprog
> >  (gdb) set env MALLOC_CHECK_=2
> >  (gdb) r
> 
> Hey, thanks a bunch.  That seems useful.  I at least get a halt right away,
> but nothing points to my code.  Instead, there's a backtrace of around 50
> function calls, starting with:
 
> #0  0x402df4c1 in kill () from /lib/libc.so.6
> #1  0x402df12a in raise () from /lib/libc.so.6
> #2  0x402e06ff in abort () from /lib/libc.so.6
> #3  0x4031a8b1 in malloc_set_state () from /lib/libc.so.6
> #4  0x40318a3c in free () from /lib/libc.so.6
> #5  0x40174855 in g_free (mem=0x808d3f0) at gmem.c:411
> #6  0x40079de6 in gtk_entry_finalize (object=0x808ce80) at gtkentry.c:537
> #7  0x400b3f9a in gtk_object_unref (object=0x808ce80) at gtkobject.c:1194
> #8  0x400b220a in gtk_object_destroy (object=0x808ce80) at gtkobject.c:247
> #9  0x400fa962 in gtk_widget_destroy (widget=0x808ce80) at gtkwidget.c:1388
> #10 0x4004625b in gtk_box_forall (container=0x808cde0, include_internals=0,
>     callback=0x804a670 <gtk_widget_destroy>, callback_data=0x0) at
> gtkbox.c:786
> #11 0x400657cb in gtk_container_foreach (container=0x808cde0,
>     callback=0x804a670 <gtk_widget_destroy>, callback_data=0x0)
>     at gtkcontainer.c:1125
> #12 0x40064834 in gtk_container_destroy (object=0x808cde0)
>     at gtkcontainer.c:631
> #13 0x400a2737 in gtk_marshal_NONE__NONE (object=0x808cde0,
>     func=0x4006478c <gtk_container_destroy>, func_data=0x0, args=0xbfffdcc4)
> 
>     at gtkmarshal.c:312
> #14 0x400ccebb in gtk_signal_real_emit (object=0x808cde0, signal_id=1,
>     params=0xbfffdcc4) at gtksignal.c:1492
> #15 0x400cb16d in gtk_signal_emit (object=0x808cde0, signal_id=1)
> 
> Now I certainly admit there might be some memory mashing going on in my app,
> but I'm at a loss to find out where / why.  What exactly does that malloc
> check do for me?

When set, GNU libc writes some extra information around memory blocks
and checks it on free() so that it can detect double frees and some
other forms of memory corruption.

Now, this might be coincidental memory corruption elsewhere in
your app (in which case you might want to look into ElectricFence),
but I guess there is a 70%-80% chance that somewhere in your
app you wrote:

 gchar *text = gtk_entry_get_text (entry);
 [...]
 g_free (text);

The returned pointer from gtk_entry_get_text() is owned by
the entry and must not be freed.

Regards,
                                        Owen