Subject: Re: pthreads since 8/08/03
To: None <current-users@NetBSD.org>
From: Joerg Sonnenberger <email@example.com>
Date: 08/15/2003 15:56:21
On Fri, Aug 15, 2003 at 10:05:36AM +0200, Alan Barrett wrote:
> On Fri, 15 Aug 2003, Gilbert Fernandes wrote:
> > ogg123: Error detected by libpthread: Destroying
> > condition variable in use.
> > Detected by file "/autobuild/HEAD/src/lib/libpthread/pthread_cond.c",
> > line 93, function "pthread_cond_destroy".
> > See pthread(3) for information.
> > Abort (core dumped)
> This usually means that the application (ogg123) has bugs, such that
> it tries to do things that are not valid in terms of the pthread
> API. NetBSD's pthread implementation detects the error and aborts the
That's right, it depends on things like unlocking unlocked mutexes.
But have a look at the following code fragement from ogg123:
IMHO the pthread_mutex_unlock should be dropped and the cleanup
Handler called, otherwise there is a race between Unlocking
the mutex and removing the cleanup handler leading to an assertion
in the pthread code. But after looking into pthread__cleanup_pop:
void pthread__cleanup_pop(int ex, void *store)
struct pt_clean_t *entry;
self = pthread__self();
entry = store;
PTQ_REMOVE(&self->pt_cleanup_stack, entry, ptc_next);
we have another race: if the thread is cancelled after PTQ_REMOVE
but before the call to the cleanup handler, the mutex is still
Since the ogg123 source is just an example could be you some guideline
what to do?
> If you have a very recent -current, read the pthread(3) man page and set
> the environment variable PTHREAD_DIAGASSERT to a value that includes "A"
> (to tell it not to abort). If you have an older -current, try setting
> PTHREAD_ERRROMODE=print or PTHREAD_ERRORMODE=ignore.
That's really necessary at the moment.
> --apb (Alan Barrett)