[Q] Assertion failure on Linux/Alpha
abnay at altavista.com
abnay at altavista.com
Wed Oct 11 07:53:38 PDT 2000
Here I go again:
I am getting the following assertion failure upon executing
kaffe on my Linux/Alpha box.
Kaffe: mem/gc-mem.c:315: gc_heap_malloc: Assertion `blk->free != 0' failed.
I found that this is caused due to the value of freelist[3]->list->free->next
being set to NULL. I placed a watchpoint and found that this is occurring
while loading the base class java/lang/Character in initBaseClasses(). Here is
the stack trace.
(gdb) info stack
#0 _wordcopy_fwd_aligned (dstp=4833959456, srcp=4833741392, len=0)
at ../sysdeps/generic/wordcopy.c:130
#1 0x2000065ae58 in memcpy (dstpp=0x120205e08, srcpp=0x1201d0a50, len=32)
at ../sysdeps/generic/memcpy.c:55
#2 0x20000145b2c in gcRealloc (gcif=0x20000288500, mem=0x1201d0a30, size=20,
fidx=538992136) at mem/gc-incremental.c:1026
#3 0x200001460d4 in jrealloc (mem=0xffffffffffe4e958, sz=0) at gc.c:27
#4 0x20000137734 in computeInterfaceImplementationIndex (clazz=0x120208600,
einfo=0x11ffff5b0) at classMethod.c:1876
#5 0x20000134a70 in processClass (class=0x120208600, tostate=5,
einfo=0x11ffff5b0) at classMethod.c:256
#6 0x20000136520 in loadStaticClass (class=0x200002886b8,
name=0x2000017c10d "java/lang/Character") at classMethod.c:1103
#7 0x20000134480 in initBaseClasses () at baseClasses.c:243
#8 0x20000134288 in initialiseKaffe () at baseClasses.c:190
#9 0x2000014b01c in JNI_CreateJavaVM (vm=0x120103808, env=0x120103810,
args=0x0) at jni.c:165
#10 0x1200011f8 in main (argc=1, argv=0x11ffff718) at main.c:138
#11 0x2000060e704 in __libc_start_main (main=0x1200010c0 <main>, argc=2,
argv=0x11ffff718, init=0x120000f60 <_init>, fini=0x120002560 <_fini>,
rtld_fini=0x2000011d850 <_dl_debug_impcalls>, stack_end=0x11ffff700)
at ../sysdeps/generic/libc-start.c:90
As I am a newbie in Kaffe land, can someone explain the gaps in my following
understanding of the flow of control?
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. 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:
(gdb) p *freelist[3]->list
$25 = {
magic = 0,
free = 0x120205e20,
next = 0x0,
nfree = 0x0,
inuse = 1,
size = 40,
nr = 194,
I am getting the following assertion failure upon executing
kaffe on my Linux/Alpha box.
Kaffe: mem/gc-mem.c:315: gc_heap_malloc: Assertion `blk->free != 0' failed.
I found that this is caused due to the value of freelist[3]->list->free->next
being set to NULL. I placed a watchpoint and found that this is occurring
while loading the base class java/lang/Character in initBaseClasses(). Here is
the stack trace.
(gdb) info stack
#0 _wordcopy_fwd_aligned (dstp=4833959456, srcp=4833741392, len=0)
at ../sysdeps/generic/wordcopy.c:130
#1 0x2000065ae58 in memcpy (dstpp=0x120205e08, srcpp=0x1201d0a50, len=32)
at ../sysdeps/generic/memcpy.c:55
#2 0x20000145b2c in gcRealloc (gcif=0x20000288500, mem=0x1201d0a30, size=20,
fidx=538992136) at mem/gc-incremental.c:1026
#3 0x200001460d4 in jrealloc (mem=0xffffffffffe4e958, sz=0) at gc.c:27
#4 0x20000137734 in computeInterfaceImplementationIndex (clazz=0x120208600,
einfo=0x11ffff5b0) at classMethod.c:1876
#5 0x20000134a70 in processClass (class=0x120208600, tostate=5,
einfo=0x11ffff5b0) at classMethod.c:256
#6 0x20000136520 in loadStaticClass (class=0x200002886b8,
name=0x2000017c10d "java/lang/Character") at classMethod.c:1103
#7 0x20000134480 in initBaseClasses () at baseClasses.c:243
#8 0x20000134288 in initialiseKaffe () at baseClasses.c:190
#9 0x2000014b01c in JNI_CreateJavaVM (vm=0x120103808, env=0x120103810,
args=0x0) at jni.c:165
#10 0x1200011f8 in main (argc=1, argv=0x11ffff718) at main.c:138
#11 0x2000060e704 in __libc_start_main (main=0x1200010c0 <main>, argc=2,
argv=0x11ffff718, init=0x120000f60 <_init>, fini=0x120002560 <_fini>,
rtld_fini=0x2000011d850 <_dl_debug_impcalls>, stack_end=0x11ffff700)
at ../sysdeps/generic/libc-start.c:90
As I am a newbie in Kaffe land, can someone explain the gaps in my following
understanding of the flow of control?
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. 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:
(gdb) p *freelist[3]->list
$25 = {
magic = 0,
free = 0x120205e20,
next = 0x0,
nfree = 0x0,
inuse = 1,
size = 40,
nr = 194,
avail = 11,
funcs = 0x120204000 '\f' <repeats 12 times>, "\a", '\f' <repeats 11 times>, "\a\n\f\024\f", '\020' <repeat
s 16 times>, "\024", '\f' <repeats 18 times>, "\020\024\020\020\020\020\f\f\a\a\f\f\f\024", '\020' <repeats
11 times>, "\024\f\f\f\f\f\f\f\f\f\f\n\020\024\f", '\020' <repeats 40 times>, "\f\f\f\f\a\f\f\f\f\f\f\f\f\f\
f\a\f\a\f\a", '\f' <repeats 14 times>, "\a\f\024\f\f",
state = 0x1202040c2 '\001' <repeats 183 times>,
data = 0x120204188 ""
}
and
(gdb) p *freelist[3]->list->free
$28 = {
next = 0x0
}
Any clues? Am I barking up the right tree?
Thanks,
Bharadwaj
(I HAVE to nail this down)
Personal e-mail : abnay at altavista.com
or abnay at altavista.net
_______________________________________________________________________
Free Unlimited Internet Access! Try it now!
http://www.zdnet.com/downloads/altavista/index.html
_______________________________________________________________________
More information about the kaffe
mailing list