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
, 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
, 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' , "\a", '\f' , "\a\n\f\024\f", '\020' , "\024", '\f' , "\020\024\020\020\020\020\f\f\a\a\f\f\f\024", '\020' , "\024\f\f\f\f\f\f\f\f\f\f\n\020\024\f", '\020' , "\f\f\f\f\a\f\f\f\f\f\f\f\f\f\ f\a\f\a\f\a", '\f' , "\a\f\024\f\f", state = 0x1202040c2 '\001' , 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@altavista.com or abnay@altavista.net _______________________________________________________________________ Free Unlimited Internet Access! Try it now! http://www.zdnet.com/downloads/altavista/index.html _______________________________________________________________________