[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