- Subject: libc/1324: sem_wait() may also have the same problem as PR# libc/1320
- From: Various
- Date: Wed Nov 10 09:28:41 1999
Topics:
libc/1324: sem_wait() may also have the same problem as PR# libc/1320
Re: libc/1324: sem_wait() may also have the same problem as PR# libc/1320
Re: libc/1324: sem_wait() may also have the same problem as PR#
Re: libc/1324: sem_wait() may also have the same problem as PR#
----------------------------------------------------------------------
Date: Fri, 24 Sep 1999 12:41:53 -0400
From: george@moberg.com
To: bugs@gnu.org
Subject: libc/1324: sem_wait() may also have the same problem as PR# libc/1320
Message-Id: <199909241641.MAA27022@delysid.gnu.org>
>Number: 1324
>Category: libc
>Synopsis: sem_wait() may also have the same problem as PR# libc/1320
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Sep 24 12:50:01 EDT 1999
>Last-Modified:
>Originator: george@moberg.com
>Organization:
net
>Release: 2.1.1pre2
>Environment:
Mandrake 6.0. Upgraded glibc to 2.1.1pre2. Upgraded gcc to 2.95.1.
Linux Kernel x86 2.2.11. gdb 4.1.17 (the one that ships w/RH w/thread support)
>Description:
I'm sort-of following up on the bug report by Greg Thompson where he says that
pthread_cond_timedwait() returns EINTR when attaching with gdb. I've seen the
same behaviour with a program which is waiting on a semaphore. sem_wait() will
return when "cont" is typed at the gdb prompt, whether or not the semaphore has
been released. Unfortunately, sem_wait() still returns 0 when this happens,
so I can't actually code around this. If it returned -1, and errno returned
EINTR, I could code around it by looping when I got EINTR.
>How-To-Repeat:
Unfortunately, I don't have a decent test program to attach with this message,
but I can get this to happen in my program, which is really big. I've worked
around this by putting sleep() calls in the code which are activated by a
command-line option
>Fix:
>Audit-Trail:
>Unformatted:
------------------------------
Date: Thu, 21 Oct 1999 10:30:01 -0400
From: Andreas Jaeger <aj@suse.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1324: sem_wait() may also have the same problem as PR# libc/1320
Message-Id: <199910211430.KAA17248@mescaline.gnu.org>
The following reply was made to PR libc/1324; it has been noted by GNATS.
From: Andreas Jaeger <aj@suse.de>
To: george@moberg.com
Cc: bugs@gnu.org
Subject: Re: libc/1324: sem_wait() may also have the same problem as PR# libc/1320
Date: 21 Oct 1999 16:18:12 +0200
>>>>> george writes:
>> Number: 1324
>> Category: libc
>> Synopsis: sem_wait() may also have the same problem as PR# libc/1320
>> How-To-Repeat:
> Unfortunately, I don't have a decent test program to attach with this message,
> but I can get this to happen in my program, which is really big. I've worked
> around this by putting sleep() calls in the code which are activated by a
> command-line option
PR 1320 has been fixed with the appended patch. Does this patch fix
your problem also?
Andreas
* condvar.c (pthread_cond_timedwait_relative): Never return with
EINTR. Patch by Andreas Schwab.
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 Jaeger
SuSE Linux Labs aj@suse.de
private aj@arthur.rhein-neckar.de
------------------------------
Date: Thu, 21 Oct 1999 11:50:01 -0400
From: "George T. Talbot" <george@moberg.com>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1324: sem_wait() may also have the same problem as PR#
libc/1320
Message-Id: <199910211550.LAA24307@mescaline.gnu.org>
The following reply was made to PR libc/1324; it has been noted by GNATS.
From: "George T. Talbot" <george@moberg.com>
To: Andreas Jaeger <aj@suse.de>
Cc: bugs@gnu.org
Subject: Re: libc/1324: sem_wait() may also have the same problem as PR#
libc/1320
Date: Thu, 21 Oct 1999 15:42:04 +0000
Andreas Jaeger wrote:
>
> >>>>> george writes:
>
> >> Number: 1324
> >> Category: libc
> >> Synopsis: sem_wait() may also have the same problem as PR# libc/1320
>
> >> How-To-Repeat:
> > Unfortunately, I don't have a decent test program to attach with this message,
> > but I can get this to happen in my program, which is really big. I've worked
> > around this by putting sleep() calls in the code which are activated by a
> > command-line option
>
> PR 1320 has been fixed with the appended patch. Does this patch fix
> your problem also?
Nope. When I type "cont" after attaching to the process, sem_wait()
still returns. Since sem_wait() is a cancellation point, I could even
re-code to do something like this:
int rv;
do
{
rv = sem_wait(&sem);
} while ((rv == -1) && (errno == EINTR));
Unfortunately, sem_wait() returns 0 even when it's fooled by the
debugger.
--
George T. Talbot
<george@moberg.com>
------------------------------
Date: Thu, 21 Oct 1999 15:42:04 +0000
From: "George T. Talbot" <george@moberg.com>
To: Andreas Jaeger <aj@suse.de>
Cc: bugs@gnu.org
Subject: Re: libc/1324: sem_wait() may also have the same problem as PR#
libc/1320
Message-ID: <380F344C.891AB580@moberg.com>
References: <199909241641.MAA27022@delysid.gnu.org> <u8hfjkyezf.fsf@gromit.rhein-neckar.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Andreas Jaeger wrote:
>
> >>>>> george writes:
>
> >> Number: 1324
> >> Category: libc
> >> Synopsis: sem_wait() may also have the same problem as PR# libc/1320
>
> >> How-To-Repeat:
> > Unfortunately, I don't have a decent test program to attach with this message,
> > but I can get this to happen in my program, which is really big. I've worked
> > around this by putting sleep() calls in the code which are activated by a
> > command-line option
>
> PR 1320 has been fixed with the appended patch. Does this patch fix
> your problem also?
Nope. When I type "cont" after attaching to the process, sem_wait()
still returns. Since sem_wait() is a cancellation point, I could even
re-code to do something like this:
int rv;
do
{
rv = sem_wait(&sem);
} while ((rv == -1) && (errno == EINTR));
Unfortunately, sem_wait() returns 0 even when it's fooled by the
debugger.
- -
George T. Talbot
<george@moberg.com>
------------------------------
End of forward73GLvK Digest
***************************