RFR (XS): 8236177: assert(status == 0) failed: error ETIMEDOUT(60), cond_wait

David Holmes david.holmes at oracle.com
Wed Mar 25 23:54:25 UTC 2020


On 26/03/2020 9:43 am, David Holmes wrote:
> Hi Gerard,
> 
> On 26/03/2020 4:03 am, gerard ziemski wrote:
>> hi all,
>>
>> Please review this "workaround" for now, which can not be called an 
>> actual fix just yet, designed to figure out why on Mac OS X, we get 
>> (very rarely) ETIMEDOUT when calling pthread_cond_wait() API. On other 
>> hand, it might actually fix it.
> 
> The ETIMEDOUT should be treated as a "spurious wakeup" and we will 
> naturally retry the wait if the condition is not yet met. All we have to 
> do to our code is adjust the assert so that ETIMEDOUT doesn't cause it 
> to fail.

And I'm happy to explicitly show this is a macOS issue (though we don't 
have an MACOS_ONLY macro)

assert_status(status == 0 BSD_ONLY(|| status == ETIMEDOUT), status, 
"cond_wait");

David

> Thanks,
> David
> 
>> According to man pages, only EINVAL is allowed as an error code here, 
>> but an inspection of the Darwin source code 
>> https://opensource.apple.com/source/libpthread/libpthread-301.1.6/src/pthread_cond.c.auto.html 
>> reveals that under some circumstances ETIMEDOUT may be returned.
>>
>> The workaround for now is to try the operation again, after a short 
>> delay (via yield() API). This will hopefully let us know whether 
>> that's enough. If not, we may try to either keep trying the same 
>> operation until it succeeds or return an error and let the code above 
>> handle it.
>>
>> The workaround applies only to OS X.
>>
>> bug link at https://bugs.openjdk.java.net/browse/JDK-8236177
>> open webrev at http://cr.openjdk.java.net/~gziemski/8236177_rev1
>> passes Mach hs-tier1,2,3,4,5
>>
>>
>> cheers


More information about the hotspot-runtime-dev mailing list