This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Bug in testsuite/gdb.base/tls.c
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: ezannoni at redhat dot com, gdb at sources dot redhat dot com
- Date: Tue, 29 Jul 2003 17:03:52 -0400
- Subject: Re: Bug in testsuite/gdb.base/tls.c
- References: <200307292007.h6TK79up016297@duracef.shout.net>
Michael Elizabeth Chastain writes:
> I'm seeing a lot of test suite hangs with the new tls.c.
> I tracked it down to this code:
>
> for( i = 0; i < N_THREADS; i++ )
> {
> do
> {
> errno = 0;
>
> if (sem_wait (&tell_main) == -1)
> {
> if (errno != EINTR)
> {
> ...
> return;
> }
> ...
> }
> }
> while (errno == EINTR);
> }
>
> It turns out that errno can be EINTR even when the return value is 0!
> That screws up the loop counter.
Whoops, never seen this one happening on my systems, just (bad) luck I guess.
>
> This happened with Red Hat Linux 8, glibc 2.2.93-5-rh. It is sensitive
> to the placement of breakpoints, which is not surprising.
>
> I think it's normal Unix semantics that when the return value is zero,
> errno has no meaning.
Yes, true.
"All semaphore functions introduced by POSIX.1b use the old error
reporting mechanism. These functions return 0 on success and -1 on
error, with errno set to the appropriate error"
Note how it carefully avoids mentioning what happens to errno in case
of success.
>
> I'll code up a patch for tls.c, on those lines.
>
thanks
elena
> Michael C