From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23283 invoked by alias); 29 Jul 2003 20:07:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23276 invoked from network); 29 Jul 2003 20:07:11 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 29 Jul 2003 20:07:11 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.9/8.12.9) with ESMTP id h6TK7Ain010444; Tue, 29 Jul 2003 15:07:10 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h6TK7AHK016299; Tue, 29 Jul 2003 15:07:10 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.9/8.12.9/Submit) id h6TK79up016297; Tue, 29 Jul 2003 16:07:09 -0400 Date: Tue, 29 Jul 2003 20:07:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200307292007.h6TK79up016297@duracef.shout.net> To: ezannoni@redhat.com Subject: Bug in testsuite/gdb.base/tls.c Cc: gdb@sources.redhat.com X-SW-Source: 2003-07/txt/msg00330.txt.bz2 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. 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. I'll code up a patch for tls.c, on those lines. Michael C