Race condition in JV_HASH_SYNCHRONIZATION in libgcj??

Tue Sep 18 19:41:00 GMT 2007

Boehm, Hans wrote:
>>> This is on a MIPS system? 
>> Yes. It is a SiByte SB1 CPU, which is a dual core mips64 device.
> Unfortunately, I'm not really up on what these do with memory
> consistency. MIPS hasn't been very acticely involved in the discussions
> we've been having about the C++ memory consistency model. But I think
> that's changing, so I may know more shortly.
>>>> The failure symptom is that the final value is
>>> one or two too low?
>> The failure is what seems to be a deadlock. Normally the 
>> test completes 
>> in about 10 seconds. Occasionally however it seems never to complete.
>>>> If I attach gdb, I can see that there are several threads in 
>> wait_unnlocked().
> Posting the stack traces for all the threads might help. Or is there a
> bug report I should be looking at?
>
Ok, I just opened a PR.
See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33479
As you can see by the stack traces, it would seem that lock bit for the 
hash entry is not being cleared. All threads are sitting there waiting 
for the lock to be cleared in wait_unlocked().
My understanding is that the lock is cleared by the release_set 
operation. Perhaps that is faulty in my implementation...
Thanks,
David Daney