Problems related to Kaffe lockObjec/unlockObject

[Godmar Back]

 You're right.  This stuff is simply broken.  

Don't use lockObject/unlockObject.  Use lockMutex/unlockMutex instead.
If you can, that is.  [ Alternatively, turn deferred-pop optimizations
off in your compiler (gcc can do that, look up the flag...) and hope
you get lucky.  This would at least allow lockObject/unlockObject
from within the same function. ]

Tim knows it's broken - maybe the handheld/pocket Linux edition of
kaffe has a fix by now?

	- Godmar

> 
> 
> Dear all,
> 	In kaffe 1.0.6, the lockObject/unlockObject in locks.c are just a wrapper
> of lockMutex/unlockMutex. In kaffe, lockObject uses "&obj" as the "where"
> parameter in lockMutex. As the lockMutex and unlockMutex support recursive
> locks, and determine whether it is a last unlock by the following checking :
> 	 if (lk->holder > where) {
> 	        putHeavyLock(lkp, lk);
> 		...
> 	}
> 	So the value of "where" is important for the unlocking.
> 	Now comes the problem.	When we call LockObject(obj) in one stack frame, the
> slot address for obj(i.e. &obj)  is the address in the current frame. But
> that slot address may be smaller than the stack address of object in a
> subsequence call to unlockObj(obj); therefore that unlockObject(obj) will
> mistakenly  assume that that is a recursive lock and won't unlock the
> object.
> 	Any comments will be appreciated. Thanks.
> 
> 	Regards,
> 	Zhu Wenzhang
>