[Q] Assertion failure on Linux/Alpha

[Patrick Tullmann]

abnay@altavista.com wrote:
> The KREALLOC at line 1876 in classMethod.c is trying to reallocate
> iface->implementors array of shorts to a size of 20. Down in gcRealloc(),
> gcRealloc() is called (line 1025) and the original memory pointed to
> by mem (which is iface->implementors of the clazz in
> computeInterfaceImplementationIndex) is copied to newmem.

I think what is happening is that a block on the freelist is being
allocated and not removed from the freelist.  

Kaffe's GC uses the data portion of a gc_unit to store the "next"
pointer in a free block.  Thus, if the block isn't really free, the
"next" pointer will overlap with the first word of data in the data
block.  Or, in your case, I'm guessing that the realloc copies the
data from the old block into the new block, which is still on the
freelist.  The data just happens to be all zeros, so it sets
next to NULL.

> What baffles me is the reason for this memcpy setting
> freelist[3]->list->free->next to NULL. Is this what it should do?
> If so I suspect some other book-keeping stuff in freelist[3] is not
> correctly updated. freelist[3]->list right after memcpy is as
> follows:

The freelist is just a list of gc_blocks. (A gc_block is a 8K chunk of
identically sized allocation units.  See kaffevm/mem/gc-mem.h for
useful comments on the data structure.)  Since a gc_block may have
some allocation units allocated and some free, each gc_block has a
linked list of free units.  

> (gdb) p *freelist[3]->list
> $25 = {
>   magic = 0, 
>   free = 0x120205e20, 
>   next = 0x0, 
>   nfree = 0x0, 
>   inuse = 1, 
>   size = 40,
>   nr = 194,
>   avail = 11, 
>   funcs = 0x120204000 <blah>
>   state = 0x1202040c2 <blah>
>   data  = 0x120204188 <blah>
> }

>From the this you can see the gc_block in question contains 40-byte
allocation units, there are 194 in the gc_block (194 \* 40 = 7760),
there are 11 available blocks, so the chain from the 'free' pointer in
the gc_block should point to a chain of 11 free objects.   ('nfree'
points to the next gc_block with 40-byte allocation units that has
a non-zero avail.  In this case, there are no more 40-byte blocks)

One odd thing is that the "magic" word at the header of the block is
not the magic value "0xdodecade".  Though the rest of the block is
well-formed...

If you run Kaffe with '-vmdebug GCDIAG' it will turn on a bunch of
sanity checks in the GC system.  That might trigger a problem earlier
in the GC.  My guess is that there is either some sort of buffer
overrun that is corrupting the gc data, or some 64-bit pointer-related 
goof (or both).

If GCDIAG doesn't turn up anything useful, you'll need to figure out
why gcRealloc is using an object that the gc_block thinks is free.
You might put some code in the gc_heap_malloc() and gc_heap_free() to
walk the freelists of this particular block and check that the
freelist has 'avail' elements in it.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann@cs.utah.edu
		   A closed mouth gathers no foot.