[kaffe] Problems with class loader and jthreads

Mon, 5 Aug 2002 09:13:17 -0700 (PDT)

Hi Godmar,
--- Godmar Back <gback@cs.utah.edu> wrote:
> 
>  jthread_disable_stop is used to defer a thread's
> termination
> to ensure the thread is stopped when it is safe to
> do so.
> You could be missing a jthread_enable_stop somewhere
> (which would
> make threads unstoppable), or the recursion could be
> legimate.
> What's your stacktrace?

#0  0x400fd861 in kill () from /lib/libc.so.6
#1  0x400fd665 in raise () from /lib/libc.so.6
#2  0x400fec81 in abort () from /lib/libc.so.6
#3  0x400f7a52 in Letext () from /lib/libc.so.6
#4  0x40074854 in jthread_disable_stop () at
jthread.c:1181
#5  0x40026332 in gc_heap_malloc (sz=20) at
mem/gc-mem.c:296
#6  0x400385fc in gcMalloc (gcif=0x40095d40, size=12,
fidx=12) at mem/gc-incremental.c:867
#7  0x40038eff in jmalloc (sz=12) at gc.c:21
#8  0x400486de in getHeavyLock (lkp=0x84a0be8) at
locks.c:158
#9  0x40048801 in slowLockMutex (lkp=0x84a0be8,
where=0xbfffb9fc) at locks.c:212
#10 0x40049389 in _lockMutex (lkp=0x84a0be8,
where=0xbfffb9fc) at locks.c:493
#11 0x401fe4db in java_lang_ClassLoader_defineClass0
(this=0x8199958, name=0x85a7ee0, data=0x8356010,
offset=0, length=7960) at ClassLoader.c:92
#12 0x0822072f in ?? ()
#13 0x082234da in ?? ()
#14 0x0823ead5 in ?? ()
#15 0x081e8546 in ?? ()
#16 0x081e8bc5 in ?? ()
#17 0x081ea5b5 in ?? ()
#18 0x40051192 in callMethodV (meth=0x8159100,
func=0x81ea3f8, obj=0x8199958, args=0xbfffc0ac,
ret=0xbfffbefc) at ../../config/i386/common.h:45
#19 0x4003de54 in Kaffe_CallObjectMethodV
(env=0x40090190, obj=0x8199958, meth=0x8159100,
args=0xbfffc0a4) at jni.c:565
#20 0x4003dee5 in Kaffe_CallObjectMethod
(env=0x40090190, obj=0x8199958, meth=0x8159100) at
jni.c:582
#21 0x40029b7c in loadClass (name=0x822d620,
loader=0x8199958, einfo=0xbfffc3c0) at
classMethod.c:1060
#22 0x40049977 in getClass (idx=180, this=0x857bf40,
einfo=0xbfffc3c0) at lookup.c:184
#23 0x4003195d in verifyBasicBlock
(codeInfo=0x84d59c8, meth=0x827d5f0, pc=0,
einfo=0xbfffc3c0) at code-analyse.c:1851
#24 0x4002e6bf in verifyMethod (meth=0x827d5f0,
pcodeinfo=0xbfffc318, einfo=0xbfffc3c0) at
code-analyse.c:333
#25 0x400688e5 in translate (xmeth=0x827d5f0,
einfo=0xbfffc3c0) at machine.c:164
#26 0x4004e063 in soft_fixup_trampoline
(_data=0x83d2c15) at soft.c:574
#27 0x40072249 in i386_do_fixup_trampoline () at
machine.c:1165
#28 0x40044303 in Kaffe_CallStaticVoidMethodA
(env=0x40090190, cls=0x857bf40, meth=0x827d5f0,
args=0x0) at jni.c:2374
#29 0x4002871d in processClass (class=0x857bf40,
tostate=11, einfo=0xbfffc85c) at classMethod.c:481
#30 0x401fe596 in java_lang_ClassLoader_resolveClass0
(this=0x8199958, class=0x857bf40) at ClassLoader.c:130
#31 0x081c5f95 in ?? ()
#32 0x081b8aa3 in ?? ()
#33 0x081ea68a in ?? ()
#34 0x40051192 in callMethodV (meth=0x8159100,
func=0x81ea3f8, obj=0x8199958, args=0xbfffcdc4,
ret=0xbfffcc14) at ../../config/i386/common.h:45
#35 0x4003de54 in Kaffe_CallObjectMethodV
(env=0x40090190, obj=0x8199958, meth=0x8159100,
args=0xbfffcdbc) at jni.c:565
#36 0x4003dee5 in Kaffe_CallObjectMethod
(env=0x40090190, obj=0x8199958, meth=0x8159100) at
jni.c:582
#37 0x40029b7c in loadClass (name=0x825f170,
loader=0x8199958, einfo=0xbfffcf08) at
classMethod.c:1060
#38 0x40049977 in getClass (idx=8, this=0x85d8860,
einfo=0xbfffcf08) at lookup.c:184
#39 0x40028239 in processClass (class=0x85d8860,
tostate=4, einfo=0xbfffcf08) at classMethod.c:204
#40 0x401fe541 in java_lang_ClassLoader_defineClass0
(this=0x8199958, name=0x85cc5a8, data=0x85f5010,
offset=0, length=1577) at ClassLoader.c:117
#41 0x0822072f in ?? ()
#42 0x082234da in ?? ()
#43 0x0823ead5 in ?? ()
#44 0x081e8546 in ?? ()
#45 0x081e8bc5 in ?? ()
#46 0x081ea5b5 in ?? ()
#47 0x40051192 in callMethodV (meth=0x8159100,
func=0x81ea3f8, obj=0x8199958, args=0xbfffd5a4,
ret=0xbfffd3f4) at ../../config/i386/common.h:45
#48 0x4003de54 in Kaffe_CallObjectMethodV
(env=0x40090190, obj=0x8199958, meth=0x8159100,
args=0xbfffd59c) at jni.c:565
#49 0x4003dee5 in Kaffe_CallObjectMethod
(env=0x40090190, obj=0x8199958, meth=0x8159100) at
jni.c:582
#50 0x40029b7c in loadClass (name=0x853dbf0,
loader=0x8199958, einfo=0xbfffd8b8) at
classMethod.c:1060
#51 0x40049977 in getClass (idx=73, this=0x857ba40,
einfo=0xbfffd8b8) at lookup.c:184
#52 0x4003195d in verifyBasicBlock
(codeInfo=0x85aa7e0, meth=0x85c98d0, pc=27,
einfo=0xbfffd8b8) at code-analyse.c:1851
#53 0x4002e6bf in verifyMethod (meth=0x85c98d0,
pcodeinfo=0xbfffd810, einfo=0xbfffd8b8) at
code-analyse.c:333
#54 0x400688e5 in translate (xmeth=0x85c98d0,
einfo=0xbfffd8b8) at machine.c:164
#55 0x4004e063 in soft_fixup_trampoline
(_data=0x85e43bd) at soft.c:574
#56 0x40072249 in i386_do_fixup_trampoline () at
machine.c:1165
#57 0x40044303 in Kaffe_CallStaticVoidMethodA
(env=0x40090190, cls=0x857ba40, meth=0x85c98d0,
args=0x0) at jni.c:2374
#58 0x4002871d in processClass (class=0x857ba40,
tostate=11, einfo=0xbfffdd54) at classMethod.c:481
#59 0x401fe596 in java_lang_ClassLoader_resolveClass0
(this=0x8199958, class=0x857ba40) at ClassLoader.c:130
#60 0x081c5f95 in ?? ()
#61 0x081b8aa3 in ?? ()
#62 0x081ea68a in ?? ()
#63 0x40051192 in callMethodV (meth=0x8159100,
func=0x81ea3f8, obj=0x8199958, args=0xbfffe2bc,
ret=0xbfffe10c) at ../../config/i386/common.h:45
#64 0x4003de54 in Kaffe_CallObjectMethodV
(env=0x40090190, obj=0x8199958, meth=0x8159100,
args=0xbfffe2b4) at jni.c:565
#65 0x4003dee5 in Kaffe_CallObjectMethod
(env=0x40090190, obj=0x8199958, meth=0x8159100) at
jni.c:582
#66 0x40029b7c in loadClass (name=0x8387590,
loader=0x8199958, einfo=0xbfffe630) at
classMethod.c:1060
#67 0x40049977 in getClass (idx=79, this=0x8501360,
einfo=0xbfffe630) at lookup.c:184
#68 0x400495e9 in getMethodSignatureClass (idx=5,
this=0x8501360, loadClass=true, isSpecial=0,
call=0xbfffe484, einfo=0xbfffe630) at lookup.c:80
#69 0x4003170d in verifyBasicBlock
(codeInfo=0x85ab010, meth=0x8514010, pc=18,
einfo=0xbfffe630) at code-analyse.c:1751
#70 0x4002e6bf in verifyMethod (meth=0x8514010,
pcodeinfo=0xbfffe588, einfo=0xbfffe630) at
code-analyse.c:333
#71 0x400688e5 in translate (xmeth=0x8514010,
einfo=0xbfffe630) at machine.c:164
#72 0x4004e063 in soft_fixup_trampoline
(_data=0x84c6fbd) at soft.c:574
#73 0x40072249 in i386_do_fixup_trampoline () at
machine.c:1165
#74 0x084830ba in ?? ()
#75 0x081c6cb7 in ?? ()
#76 0x0825c9cf in ?? ()
#77 0x40051172 in callMethodV (meth=0x8261010,
func=0x8124d48, obj=0x0, args=0xbfffec14,
ret=0xbfffea78) at ../../config/i386/common.h:38
#78 0x40044175 in Kaffe_CallStaticVoidMethodV
(env=0x40090190, cls=0x825c2c0, meth=0x8261010,
args=0xbfffec10) at jni.c:2344
#79 0x40044204 in Kaffe_CallStaticVoidMethod
(env=0x40090190, cls=0x825c2c0, meth=0x8261010) at
jni.c:2357
#80 0x08048e1e in main2 (env=0x40090190,
argv=0xbffff0e4, farg=2, argc=1) at main.c:233
#81 0x08048cbd in main (argc=3, argv=0xbffff0e4) at
main.c:145
#82 0x400ec7ee in __libc_start_main () from
/lib/libc.so.6

The ClassLoader.defineClass0 and resolveClass0
functions are unmodified.

I'm a little puzzled, as trivial programs work, like
kaffe at.dms.kjc.Main --help . I am not sure about the
recursion: there is one with defineClass0 &
resolveClass0, with different classes, though.
defineClass0 tries to get a lock on centry and that's
where it crashes.

From what you've said, it may be that the
define/resolveClass0 resursion creates locks that
implicitely deferr thread destruction until the
assertion is flagged. So when I increase the limit to
50, all tests pass.

best regards,

dalibor topic

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com