From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-14940-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 5697 invoked by alias); 29 Jul 2003 20:56:26 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 5677 invoked from network); 29 Jul 2003 20:56:26 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sources.redhat.com with SMTP; 29 Jul 2003 20:56:26 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6TKuPZ30357
	for <gdb@sources.redhat.com>; Tue, 29 Jul 2003 16:56:25 -0400
Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6TKuPI11514
	for <gdb@sources.redhat.com>; Tue, 29 Jul 2003 16:56:25 -0400
Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46])
	by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6TKuNL28449;
	Tue, 29 Jul 2003 16:56:24 -0400
Received: by localhost.redhat.com (Postfix, from userid 469)
	id 4E2312CB2C; Tue, 29 Jul 2003 17:03:53 -0400 (EDT)
From: Elena Zannoni <ezannoni@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16166.57656.743881.52826@localhost.redhat.com>
Date: Tue, 29 Jul 2003 20:56:00 -0000
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: ezannoni@redhat.com, gdb@sources.redhat.com
Subject: Re: Bug in testsuite/gdb.base/tls.c
In-Reply-To: <200307292007.h6TK79up016297@duracef.shout.net>
References: <200307292007.h6TK79up016297@duracef.shout.net>
X-SW-Source: 2003-07/txt/msg00331.txt.bz2

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