Re: Any problems with malloc functions?

[Owen Taylor <otaylor REDHAT COM>]

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