[kaffe] Problems with class loader and jthreads

[Godmar Back]

 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?

	- Godmar

> 
> hi,
> 
> I've written a patch that lets SystemClassLoader
> extend from URLClassLoader and adds limited (just
> CodeSources without certificates) ProtectionDomain
> handling to class loading. It lets the bootstrap class
> loader take care of classes in java and kaffe
> packages, while using SystemClassLoader to load the
> rest.
> 
> Trivial programs work, but compiling classes from our
> regression tests suite crashes with my patch with:
> 
> slowLockMutex(**lkp=0x84a5be8, where=0xbfffb9d8,
> th=0x811a030)
>   getHeavyLock(**lkp=0x84a5be8, *lk=0xbfffc0dc,
> th=0x811a030)
>     got new lock
> kaffe-bin: jthread.c:1181: jthread_disable_stop:
> Assertion `currentJThread->stopCounter < 10' failed.
> 
> 
> The assert has an associated commented : 
> /* XXX Shouldn't recurse that much... ever...
> hopefully. */
>                 assert(currentJThread->stopCounter <
> 10);  
> 
> As I have no experience hacking on jthreads, I'm
> wondering if someone could explain me what
> jthread_disable_stop is used for, what it has to do
> with recursion, and what a possible source for the
> recursion could be?
> 
> thanks for any suggestions,
> 
> dalibor topic
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> 
> _______________________________________________
> kaffe mailing list
> kaffe@kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
>