[Kaffe] core dump while running kaffe.

Godmar Back gback at cs.utah.edu
Sun Mar 21 18:16:47 PST 1999


 Thanks.

What's happening is that a thread holds the utf8 lock while a garbage
collection finishes.  Since we synchronously free classes and related
data structures, the gc thread attempts to grab the utf8 lock, resulting
in a deadlock.  The same is possible for the stringLock, btw, despite
the precautionary measure of giving it up before calling malloc().

Hmmm, I think I can either patch it up by having the gc thread grab
the utf8 & string lock before it starts (just like it now grabs the 
allocator lock), or I could get rid of the utf8 and string locks in
favor of a global "master" allocation lock.

	- Godmar

> 
> Hello.
> 
> I just got a strange core dump in kaffe. I hope this stack trace
> will help in tracking down the problem.
> 
> 
> (gdb) bt
> #0  0xef407418 in _libc_kill ()
> #1  0xef3ba568 in abort ()
> #2  0xef4bf9a0 in initNativeThreads (nativestacksize=2296)
>     at ../../../kaffe/kaffevm/thread.c:493
> #3  0xef4d9ad0 in reschedule ()
>     at ../../../../../kaffe/kaffevm/systems/unix-jthreads/jthread.c:1496
> #4  0xef4d7f9c in suspendOnQThread (jtid=0x160010, queue=0x923bc, timeout=0)
>     at ../../../../../kaffe/kaffevm/systems/unix-jthreads/jthread.c:759
> #5  0xef4da0f8 in jmutex_lock (lock=0x923b8)
>     at ../../../../../kaffe/kaffevm/systems/unix-jthreads/jthread.c:1743
> #6  0xef4bb3fc in __lockMutex (lk=0xef4f7e20)
>     at ../../../kaffe/kaffevm/locks.c:315
> #7  0xef4bfef8 in utf8ConstRelease (utf8=0x17a9e8)
>     at ../../../kaffe/kaffevm/utf8const.c:173
> #8  0xef4c0700 in destroyClass (collector=0xef4f790c, c=0x5a6798)
>     at ../../../kaffe/kaffevm/gcFuncs.c:89
> #9  0xef4abf90 in finishGC (gcif=0xef4f790c)
>     at ../../../kaffe/kaffevm/mem/gc-incremental.c:579
> #10 0xef4ab8e0 in gcMan (arg=0xef4fa4d0)
>     at ../../../kaffe/kaffevm/mem/gc-incremental.c:416
> #11 0xef4d8c50 in start_this_sucker_on_a_new_frame ()
>     at ../../../../../kaffe/kaffevm/systems/unix-jthreads/jthread.c:1142
> #12 0xef4d8d84 in jthread_create (pri=11 '\013', func=0xef4ab5bc <gcMan>, 
>     daemon=1, jlThread=0x148800, threadStackSize=32768)
>     at ../../../../../kaffe/kaffevm/systems/unix-jthreads/jthread.c:1191
> #13 0xef4bf174 in createThread (tid=0x148800, func=0xef4ab5bc)
>     at ../../../kaffe/kaffevm/thread.c:104
> #14 0xef4bf438 in createDaemon (func=0xef4ab5bc, nm=0xef4dde00 "gc", prio=11)
>     at ../../../kaffe/kaffevm/thread.c:225
> #15 0xef4acab4 in gcEnable (collector=0xef4f790c)
>     at ../../../kaffe/kaffevm/mem/gc-incremental.c:880
> #16 0xef4a1ad4 in initialiseKaffe ()
>     at ../../../kaffe/kaffevm/baseClasses.c:148
> #17 0xef4b0dc0 in JNI_CreateJavaVM (vm=0x30474, env=0x30328, args=0x302d4)
>     at ../../../kaffe/kaffevm/jni.c:168
> #18 0x11fdc in main (argc=1, argv=0xefffefac)
>     at ../../../kaffe/kaffe/main.c:107
> 
> 
> thanks
> Mo DeJong
> dejong at cs.umn.edu
> 
> 



More information about the kaffe mailing list