[kaffe] Re: Solaris pthread broken...
Dalibor Topic
robilad at kaffe.org
Thu Jun 3 10:10:05 PDT 2004
Riccardo wrote:
>>thank you very much for your bug report, I've checked in a fix for the
>>java.lang.NoClassDefFoundError. I haven't got around to fixing the
>>LDFLAGS yet.
>>
>
>
> Thanks to you. I did a fresh compile today. It doesn't work and is even
> worse than 2 days ago :'
> Compiling classes from @essential.files using /home/multix/kaffe-cvs/
> sunos-build/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M at.dms.kjc.Main
> [ start compilation in verbose mode ]
>
>
> it will stay here forever.
Ciao Riccardo,
thanks!
> I attached gdb to kaffe-bin
>
> a bt gives me only:
>
> (gdb) bt
> #0 0xef3b76e4 in door_restart ()
that function is not from kaffe. You'll have to ask some other
sparc-solaris developer what that means.
> i hit continue... and typed ctrl-c
> made a new backtrace:
>
> (gdb) bt
> #0 0xef294ca8 in __sigprocmask ()
> #1 0xef28b684 in __bounceself ()
> #2 0xef28a050 in _sema_wait_cancel ()
> #3 0xef484754 in _sem_wait ()
> #4 0xef737e80 in jthread_unsuspendall ()
> at ../../../../../kaffe/kaffe/kaffevm/systems/unix-pthreads/thread-
> impl.c:1098
> #5 0xef6e2b30 in gcMan (arg=0xef753038)
> at ../../../kaffe/kaffe/kaffevm/mem/gc-incremental.c:737
At the moment, there is just a for loop at that line. Seems like the CVS
source has been patched since your test. It would be nice if you could
try again with curent CVS head.
> #6 0xef7012cc in startSpecialThread (arg=0x3ea480)
> at ../../../kaffe/kaffe/kaffevm/thread.c:305
> #7 0xef7376c8 in tRun (p=0x396c38)
> at ../../../../../kaffe/kaffe/kaffevm/systems/unix-pthreads/thread-
> impl.c:57
There is a digit missing here! There is no function tRun on line 57.
> I don't know if that can help though.
That seems to indicate that sem_wait waits successfully on another
thread to post to the semaphore. You could try looking at the output of
-vmdebug JTHREAD,JTHREADDETAIL to see what's happening underneath.
The comment for jthread_suspendall has an interesting line: "Make sure
no suspended thread blocks on a resource (mutexed non-reentrant lib
func) we use within the critical section, or we have a classical
deadlock." So you could try to investigate in that direction.
cheers,
dalibor topic
More information about the kaffe
mailing list