From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23380 invoked by alias); 23 Aug 2004 13:16:00 -0000 Mailing-List: contact glibc-bugs-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sources.redhat.com Received: (qmail 23366 invoked by uid 48); 23 Aug 2004 13:15:58 -0000 Date: Mon, 23 Aug 2004 13:16:00 -0000 From: "sebastien dot decugis at ext dot bull dot net" To: glibc-bugs@sources.redhat.com Message-ID: <20040823131554.342.sebastien.decugis@ext.bull.net> Reply-To: sourceware-bugzilla@sources.redhat.com Subject: [Bug nptl/342] New: Threads hang after condvar destruction X-Bugzilla-Reason: CC X-SW-Source: 2004-08/txt/msg00177.txt.bz2 List-Id: The POSIX standard requires that it is safe to destroy a condvar when no more threads are blocked on it, even if the threads are still inside the pthread_cond_{timed}wait routine. Please refer to the pthread_cond_destroy() page and especially to the Example section. The current implementation does not respect this assertion. The routines pthread_cond_wait or timedwait still need to access some condition data, but the pthread_cond_destroy succeeds anyway. The result is a hang when the memory of the destroyed condvar is re-used. Maybe the pthread_cond_destroy should block until every other thread leaves the pthread_cond_* routines, as it is done in the barriers? -- I'm not sure if this is possible... Regards, Sebastien. -- Summary: Threads hang after condvar destruction Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: nptl AssignedTo: drepper at redhat dot com ReportedBy: sebastien dot decugis at ext dot bull dot net CC: glibc-bugs at sources dot redhat dot com GCC build triplet: gcc3.4.1 http://sources.redhat.com/bugzilla/show_bug.cgi?id=342 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.