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
>
