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.
Created attachment 170 [details] This files shows the problem This file would return 0 if the implementation conformed to POSIX. It hang for 120 sec then timeout currently.
Should be fixed in CVS.
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
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.
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.