[EMAIL PROTECTED] wrote: > On Wed, 06 September 2000, Patrick Tullmann wrote: > > Okay, so its not a JIT-specific problem. Can you run with '-vmdebug > > GCDIAG' on the interpreter and give me a backtrace to the problem from > > GDB? > > Here it is: > > user@hostname:~/kaffe-1.0.6% kaffe -vmdebug GCDIAG >test/regression/HelloWorldApp.java > [...] > #6 0x2000014606c in jmalloc (sz=6) at gc.c:21 > #7 0x2000014218c in findClassInJar (cname=0x120205e30 "java/lang/Short.class", >einfo=0x11ffff840) > at findInJar.c:221 Okay, so it blows up in the same place with and without GCDIAG, so its probably something that happens immediately before loading java.lang.Short. This stuff is happening before locking or threads are set up, so its not one of those problems. The nice thing about no threads, is that this should be a deterministic problem. :) The class loaded immediately before java.lang.Short is java.lang.Character which is a rather large and complicated class. However, it isn't brought beyond CSTATE_LINKED, so much of the complexity isn't touched. At this point, I think someone is going to have to really run the debugger on this and figure out what's changing in the GC block. It could be the jar-parsing code (test by un-jar'ing Klasses and looking up only uncompressed files) or the class parsing code. Sorry there wasn't a simple fix. -Pat ----- ----- ---- --- --- -- - - - - - Pat Tullmann [EMAIL PROTECTED] Indifference may cause the downfall of mankind, but who really cares?
