Astonishing allocation bug in glib-2.16.4 compiled with gcc 2.96

[Alessandro Vesely <vesely tana it>]

Hi,
I've compiled glib, and make check worked fine. Next, I compiled the 
"mono" package, which uses it. It compiled almost ok (few twists 
needed on a pre-C99 compiler) but make check freezes. After some 
tinkering I found out that freezing occurs because of circular list.

The functions involved only call glib's list find, append, and 
eventually free functions. I'm quite astonished at serendipitously 
finding such a paramount bug in a frequently used package. However, I 
patched g_slist_append like so:

--- glib/gslist.original.c	Wed Jul  2 00:30:12 2008
+++ glib/gslist.c	Sun Jul 13 11:33:06 2008
@@ -121,7 +121,9 @@
   if (list)
     {
       last = g_slist_last (list);
-      /* g_assert (last != NULL); */
+      if (last == NULL || last->next != NULL || last == new_list)
+        g_print("GOT BUG: last=%p, next=%p, new=%p\n",
+          last, last->next, new_list);
       last->next = new_list;

       return list;

and then while checking "mono", it triggered it

GOT BUG: last=0x82b61a0, next=(nil), new=0x82b61a0

Although I'm inclined to think the bug is due to the old compiler, I 
cannot change it because that would require altering libc on the 
target system (built on RedHat 7.2) installed by the hardware vendor,
and that's out of my reach.

In facts, 0x82b61a0 was used and freed various times before eventually 
being allocated twice on two consecutive loops of the client code. The 
client function (visit_bb in mono's liveness.c) starts with an empty 
list and appends elements as it recursively walks a tree, in order to 
avoid visiting the same elements. The bug reproduces deterministically 
every time I launch that specific invocation of "mono". However, the 
allocation code in gslice.c is quite intricate and it's not clear to 
me how to proceed. I'll try and reconfigure glib with CFLAGS="-O0 -g", 
and see if that changes anything. Can anybody suggest anything better?

TIA
Ale