This is sources Bugzilla
Bugzilla Version 2.17.5
Bugzilla Bug 342
  Threads hang after condvar destruction Last modified: 2006-04-01 20:03:07
     Query page      Enter new bug
Bug#: 342   Hardware:   Reporter: Sebastien Decugis <sebastien.decugis@ext.bull.net>
Host: Target: Build:
Product:     Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: RESOLVED   Priority:  
Resolution: FIXED   Severity:  
Assigned To: Ulrich Drepper <drepper@redhat.com>   Target Milestone:  
Flags: Requestee:
  backport ()
  examined ()
  testsuite ()
Summary:
Keywords:

Attachment Description Type Created Actions
pthread_cond_destroy.c This files shows the problem text/x-csrc 2004-08-23 13:31 Edit None
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 342 depends on: Show dependency tree
Show dependency graph
Bug 342 blocks:

Additional Comments:


Leave as RESOLVED FIXED
Reopen bug
Mark bug as VERIFIED

View Bug Activity   |   Format For Printing


Description:   Last confirmed: 0000-00-00 00:00 Opened: 2004-08-23 13:15
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.

------- Additional Comment #1 From Sebastien Decugis 2004-08-23 13:31 -------
Created an attachment (id=170)
This files shows the problem

This file would return 0 if the implementation conformed to POSIX. It hang for
120 sec then timeout currently.

------- Additional Comment #2 From Jakub Jelinek 2004-09-03 08:08 -------
Should be fixed in CVS.

------- Additional Comment #3 From Sundararajan 2006-03-29 15:25 -------
I am using a RedHat Linux Enterprise version.

uname -a would give
Linux xyz220 2.6.9-22.EL #1 Mon Sep 19 18:20:28 EDT 2005 i686 i686 i386 GNU/Linux

I get the hang state on using the call pthread_cond_destroy

if( pthread_mutex_destroy(&lock->mutex) == EBUSY)
    {
       printf(xfp, "\n this is after destroy mutex ebusy");
    }
if (lock->recursive) {
pthread_cond_destroy ( &lock->cv )
}

Can I know if this has been resolved , if so, what;s the patch information.
if not, what;s the proposed solution.

thanks and regards
sundar

------- Additional Comment #4 From Ulrich Drepper 2006-04-01 20:03 -------
Stop asking questions about distributions here.  If you have problems with the
distribution ask the paid support.  If you don't pay for support ask in some
forum dedicated to that distribution.

     Query page      Enter new bug
Actions: New | Query | bug # | Reports | Requests   New Account | Log In