[kaffe] reproducible lockup with jit3 in System.runFinalization()

[Noa Resare]

On tis, 2004-09-14 at 23:40 +0200, Noa Resare wrote:
> continuing with the detective work to get mauve to work with cvs kaffe
> on my box i found a lockup in System.runFinalization(). When I run the
> attached code the kaffe-bin process hangs with 100% CPU usage. When
> attaching to the process with strace i get this:

I have made some progress narrowing this down. The following takes place
in /kaffe/kaffevm/kaffe-gc/gc-mem.c

Somewhere a gc_block structure (let's call it EVIL) gets added to
another list without first being removed from prim_freelist. When
gc_primitive_free() merges EVIL with another recently free'd gc_block it
calls gc_remove_from_prim_freelist(EVIL). Because EVIL was added to
another list after prim_freelist it gets removed from that list and
stays on prim_freelist. A few cycles later it gets added once more to
prim_freelist, and once prim_freelist has one entry twice it loops
infinitely in gc_add_to_prim_freelist() trying to find the end of the
list.

Now fixing it is just a matter of finding that other addition, that
messes up the EVIL->free value causing it to be removed from the wrong
list.

To track this down I would suggest that routines that add gc_block
structures requires that their free member is set to NULL. routines that
detach gc_block structures from a list is responsible for setting free
to NULL.

What do people think about that? Perhaps there are other esoteric error
conditions that would also be uncovered by such a convention.

cheers/noa

-- 
And the lions ate the christians and the christians burned the witches,
and even I am out of explanations -- Ola Salo
gpg fingerprint: F3C4 AC90 B885 FE15 344B  4D05 220B 7662 A190 6F09