Re: [greg@surety.com] libc/1320: pthread_cond_timedwait returns EINTR in multithreaded processes when gdb is attached to them

[Andreas Schwab <schwab at suse dot de>]

Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:

|> Hi,
|> 
|> the following bug report has been send to glibc and describes a
|> problem in the interaction of glibc and gdb.
|> 
|> I can reproduce the problem with HJ Lu's gdb 4.17.0.12 and with gdb
|> 19990913 from CVS.

SUS2 says that pthread_cond_timedwait must never return with EINTR.  If it
is interrupted it must either continue waiting or return zero.  I think
continue waiting is the desired action.

I'm not sure whether this is the right way to fix the bug.

Index: linuxthreads/condvar.c
===================================================================
RCS file: /glibc/cvsfiles/libc/linuxthreads/condvar.c,v
retrieving revision 1.6
diff -u -a -u -r1.6 linuxthreads/condvar.c
--- linuxthreads/condvar.c	1998/10/29 14:34:17	1.6
+++ linuxthreads/condvar.c	1999/09/24 16:27:20
@@ -76,6 +76,7 @@
   enqueue(&cond->__c_waiting, self);
   __pthread_unlock(&cond->__c_lock);
   pthread_mutex_unlock(mutex);
+ continue_waiting:
   /* Set up a longjmp handler for the restart and cancel signals */
   if (sigsetjmp(jmpbuf, 1) == 0) {
     THREAD_SETMEM(self, p_signal_jmp, &jmpbuf);
@@ -113,13 +114,16 @@
     pthread_mutex_lock(mutex);
     pthread_exit(PTHREAD_CANCELED);
   }
-  /* If not signaled: also remove ourselves and return an error code */
+  /* If not signaled: also remove ourselves and return an error code, but
+     only if the timeout has elapsed.  If not, just continue waiting. */
   if (THREAD_GETMEM(self, p_signal) == 0) {
+    if (retsleep != 0)
+      goto continue_waiting;
     __pthread_lock(&cond->__c_lock, self);
     remove_from_queue(&cond->__c_waiting, self);
     __pthread_unlock(&cond->__c_lock);
     pthread_mutex_lock(mutex);
-    return retsleep == 0 ? ETIMEDOUT : EINTR;
+    return ETIMEDOUT;
   }
   /* Otherwise, return normally */
   pthread_mutex_lock(mutex);

-- 
Andreas Schwab                                  "And now for something
SuSE Linux Labs                                  completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg