GTK+ 1.2.10 on Solaris has segfault inside malloc

["Eric M. Monsler" <emonsler beamreachnetworks com>]

All,

I am having a problem with gtk+ on a Solaris box.  It's 1.2.10, 
configured and compiled on the machine.  I really can't afford the time 
to port up to gtk+2.x right now, especially since I use the gtkextra 
library for plotting, which is only partially ported itself.

The application is a display used for debugging embedded code.  The 
embedded code sends messages that contain all kinds of trash, and I have 
done a lot of input checking to make the application as bulletproof as I 
can.

But, now I have a situation where one developer is crashing the display 
with some regularity.  About once a day.  And, the crashes always occur 
when printing something to a string, and the segfault is inside 
*malloc*!  Even if the crash were in g_strdup_vprintf() I would be 
surprised, there should be no invalid data for a format string of "%lu", 
at least that I can think of.

Given that the display will handle some hundreds of messages, each with 
50-75 updates, stepping through the code looking for the crash is not 
very practical.

Below is the stack trace.

Any help would be greatly appreciated.


emonsler morpheus:src$ uname -a
SunOS morpheus 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-Enterprise


(gdb) bt
#0  0xfec41bec in realfree () from /usr/lib/libc.so.1
#1  0xfec424f8 in cleanfree () from /usr/lib/libc.so.1
#2  0xfec4162c in _malloc_unlocked () from /usr/lib/libc.so.1
#3  0xfec41520 in malloc () from /usr/lib/libc.so.1
#4  0xfef4dd24 in g_malloc (size=16) at gmem.c:177
#5  0xfef5db44 in g_strdup_vprintf (format=0xd3f89 "%lu", args1=0xffbef7ac)
    at gstrfuncs.c:156
#6  0xfef61a7c in g_string_sprintfa_int (string=0xbe060, fmt=0xd3f89 "%lu",
    args=0xffbef7ac) at gstring.c:483
#7  0xfef61af0 in g_string_sprintf (string=0xbe060, fmt=0xd3f89 "%lu")
    at gstring.c:498
#8  0x2230c in vGenMetDispMsgHandling (pDestHdr=0xe3c28, pData=0xc8218)
    at avd_genmet.c:2176
#9  0x30038 in vPassMessageToDisplay (pDestHdr=0xe3c28, pMainState=0x45348)
    at avd_disp_msgs.c:1033
#10 0x30c64 in vReadIncomingUDP (pData=0x45348, udp_fd=5,
    condition=GDK_INPUT_READ) at avd_disp_msgs.c:1490
#11 0xff0b2964 in gdk_io_invoke (source=0x45a80, condition=G_IO_IN,
    data=0x45a68) at gdkevents.c:882
#12 0xfef48b3c in g_io_unix_dispatch (source_data=0x46688,
    current_time=0xffbefb78, user_data=0x45a68) at giounix.c:135
#13 0xfef4ba98 in g_main_dispatch (dispatch_time=0xffbefb78) at gmain.c:656
#14 0xfef4c7bc in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#15 0xfef4ca94 in g_main_run (loop=0x60ff8) at gmain.c:935
#16 0xff217434 in gtk_main () at gtkmain.c:524
#17 0x15048 in main (argc=3, argv=0xffbefd7c) at avd_main.c:307
(gdb)

I went up the backtrace to g_malloc(), the first place that I could 
inspect code, and saw the following:

(gdb) list
172     #ifdef ENABLE_MEM_CHECK
173       size += SIZEOF_LONG;
174     #endif /* ENABLE_MEM_CHECK */
175
176
177       p = (gpointer) malloc (size);
178       if (!p)
179         g_error ("could not allocate %ld bytes", size);
180
181
(gdb) display size
(gdb) print size
$1 = 16
(gdb)



Thanks,

Eric