Re: Any problems with malloc functions?

[Ken Stebbings <kens ecg csg mot com>]

I just got glib/gtk+ 1.13 and I still have problems relating to memory
management, but hopefully it will be easier to track them down now. 
When I compiled and ran testgtk, it coredumps right away:

(gdb) bt
#0  0xc009f60c in memorymap ()
#1  0xc009d654 in free ()
#2  0xc1e76910 in g_free (mem=0x40003540) at gmem.c:394
#3  0xc238a7dc in gtk_label_set_text_internal (label=0x40026948, 
    str=0x40027198 "Gtk+ v1.1.13", str_wc=0x40027158) at gtklabel.c:224
#4  0xc238aaec in gtk_label_set_text (label=0x40026948, 
    str=0x7b03af08 "Gtk+ v1.1.13") at gtklabel.c:262
#5  0xc238a6ec in gtk_label_new (str=0x40026948 "@\002aČ") at
gtklabel.c:213
#6  0x25bb0 in create_main_window () at testgtk.c:8433
#7  0x25fdc in main (argc=1, argv=0x7b03ab84) at testgtk.c:8505
(gdb) 

With 1.12, it hung trying to malloc something, in 1.13 it dumps freeing
something.  I recompiled glib1.13 with --enable-mem-check,
--enable-mem-profile, and --enable-debug=yes.  Now testgtk doesn't
coredump, but buttons and some other widgets have no text on them (but
there is text in the clist).  The tests seem to work (as far as I
remember them from previous versions!)  I get a ton of these messages:

Gdk-CRITICAL **: file gdkdraw.c: line 207 (gdk_draw_string): assertion
`string != NULL' failed.

I'm assuming that somwhere in the button routines text is not getting
malloc'ed correctly or is being free'd twice, as Owen said.  Hopefully
I'll get time to dig into the source in search of the problem this
afternoon.  If anyone has any pointers as to where to look, I'd greatly
appreciate the input.  Even without the text it looks like there's some
super cool new stuff!!

Ken

Owen Taylor wrote:
> 
> Ken Stebbings <kens@ecg.csg.mot.com> writes:
> 
> > I just compiled (actually several times) glib/gtk+ 1.11, they compile
> > file but the testgtk program hangs without ever displaying anything.
> > Here's bt:
> >
> > (gdb) bt
> > #0  0xc009d070 in malloc ()
> > #1  0xc1fb0fe8 in g_malloc (size=10) at gmem.c:170
> > #2  0xc1fbd8b4 in g_strdup (str=0x7afb952c "GtkButton") at
> > gstrfuncs.c:46
> > #3  0xc2161a60 in gtk_type_unique (parent_type=40213,
> > type_info=0x7afb950c)
> >     at gtktypeutils.c:248
> > #4  0xc202f734 in gtk_button_get_type () at gtkbutton.c:115
> > #5  0xc202ff58 in gtk_button_new () at gtkbutton.c:287
> > #6  0xc2030054 in gtk_button_new_with_label (label=0xb7b0 "button box")
> >     at gtkbutton.c:296
> > #7  0x25c60 in create_main_window () at testgtk.c:8452
> > #8  0x25fd4 in main (argc=1, argv=0x7b03ab84) at testgtk.c:8505
> > (gdb)
> >
> > It appears that malloc never returns.  It does seem to chew up CPU
> > though.  I am running on an HP 735 running HPUX 10.20.  Are there known
> > problems on this platform?  Or are the HP memory functions horribly
> > broken?  Any help would be greatly appreciated, as I am really pulling
> > my hair out on this one.  The previous versions of glib/gtk work
> > flawlessly.
> >
> > Sorry if this issue is old, I can't find messages on the web archive
> > from this year.
> 
> (I think the archive is just lagged. Though it is a bit strange
>  that the last message is on Dec 31)
> 
> This problem has not been reported before. Generally, I'd
> say that if malloc() hangs, it probably means that memory
> has been corrupted in some fashion somewhere else - a
> double free(), or a buffer-overwrite. :-(
> 
> Since this doesn't seem to occur on other platforms, it
> may be rather nasty to debug. Do other GTK+ programs
> show the same problem. For instance, the gtk/simple
> program?
> 
> Could you try out 1.1.12 and see if that helps?
> (Actuallyy, 1.1.13 should be coming out in the next
> day or so.)
> 
>                                         Owen