We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2598

Summary: SDL_CondWaitTimeout() and EAGAIN
Product: SDL Reporter: Alexander Sabourenkov <llxxnntt>
Component: threadAssignee: Sam Lantinga <slouken>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: HG 2.1   
Hardware: x86   
OS: Linux   

Description Alexander Sabourenkov 2014-06-21 10:28:31 UTC 
SDL_CondWaitTimeout() pthread implementation does not handle EAGAIN from pthread_cond_wait(). EAGAIN from it has now been seen in the wild (linux 3.13 glibc 2.19).

This causes SDL_CondWaitTimeout() to report "pthread_cond_timedwait() failed".

Granted, pthread_cond_timedwait does not list EAGAIN in the Errors section.
However, I feel it should be handled anyway. Something like:


--- a/src/thread/pthread/SDL_syscond.c    Fri Jun 20 22:38:36 2014 -0400
+++ b/src/thread/pthread/SDL_syscond.c    Sat Jun 21 14:16:41 2014 +0400
@@ -118,6 +118,7 @@
     retval = pthread_cond_timedwait(&cond->cond, &mutex->id, &abstime);
     switch (retval) {
     case EINTR:
+    case EAGAIN:
         goto tryagain;
         break;
     case ETIMEDOUT:
Comment 1 Alexander Sabourenkov 2014-06-21 15:38:22 UTC 
Please disregard the above.

Seems like flooding a process under gdb with ptrace_attach() calls (which most, but not all, fail as expected) sometimes, rarely, causes pthreah_cond_timedwait() to return EINVAL.

I have no idea why is this happening or what to do with that, so let's just skip that very corner case.