Re: A Bug in pthread_cond_destroy?
Re: A Bug in pthread_cond_destroy?
- Subject: Re: A Bug in pthread_cond_destroy?
- From: Terry Lambert <email@hidden>
- Date: Thu, 10 Jan 2008 09:31:47 -0800
On Jan 10, 2008, at 5:09 AM, Kazuho Oku <email@hidden> wrote:
2008/1/10, Jim Magee <email@hidden>:
Yes, I saw the quote about it being "safe to destroy a mutex on which
no thread is waiting" but the fact that the sentence and paragraph
before said that attempting to use such a destroyed condition would
result in undefined behavior still holds.
Well, my example never calls pthread_cond_wait AFTER calling
pthread_cond_destroy. Maybe I was vague on my explatation, what
happens is:
1) thread-A enters pthread_cond_wait
2) thread-B enters pthread_cond_signal
3) thread-A returns from pthread_cond_wait
4) thread-A calls pthread_cond_destroy
5) thread-A returns from pthread_cond_destroy (returns 0)
6) thread-B read & writes the conditional
7) thread-B returns from pthread_cond_signal
which from my understanding is the exact case the spec describes as
"it shall be safe to destroy an initialized condition variable upon
which no threads are currently blocked."
Safe to destroy it, not safe to do anything else. Your step 6 is only
legal on on an undestroyed mutex.
-- Terry
Or if what you are trying to say is that the above sequence is valid
by the pthread specification, sorry for bothering your time.
In your case, the destroy _was_ done safely (the destroy didn't hang
or have any other odd behavior, correct?). It was the attempt to use
the destroyed condition variable that caused problems - and that is
exactly what the spec says is undefined. So, I think our
implementation meets the spec.
--Jim
On Jan 9, 2008, at 8:01 AM, Kazuho Oku wrote:
2008/1/9, Jim Magee <email@hidden>:
I think you are assuming behavior that isn't specified.
Specifically, the
definition for pthread_cond_destroy() says:
The pthread_cond_destroy() function shall destroy the given
condition
variable specified by cond; the object becomes, in effect,
uninitialized. An
implementation may cause pthread_cond_destroy() to set the object
referenced
by cond to an invalid value. A destroyed condition variable object
can be
reinitialized using pthread_cond_init(); the results of otherwise
referencing the object after it has been destroyed are undefined.
Thank you for your response, I did not know such a statement
exists in
pthread spec., maybe I was referring to an older document.
Thas said, I googled and found a spec. that includes your quotes
(http://www.opengroup.org/onlinepubs/007908775/xsh/pthread_cond_destroy.html
),
and if you are referrring to it, my understaning is that it states
It shall be safe to destroy an initialized condition variable upon
which no threads are currently blocked.
which is the case in my example. My understanding is that their is
the case where a waiting thread get signalled and woke up and may
destroy the cond before the signalling thread finishes modifying the
pthread_cond_t variable.
Or if there's any other version, would you please let me know?
Thank you in advance.
So, trying to call pthread_cond_signal() from another thread after
the
condition is destroyed (or even "during" it being destroyed) can
result is
undefined behavior. You really need synchronization of your own to
avoid
issues there. Using the same mutex would have been good enough.
Since that
isn't in your model, you need something else (maybe a second
condition
variable that indicates whether the first has been destroyed? -
just
thinking out loud).
--Jim
On Jan 9, 2008, at 2:25 AM, Kazuho Oku wrote:
Hi,
If this is not the right place to report bugs of libc, please
tell me
the right mailing list. Thank you in advance, and sorry, if it is
the
case.
I think I have found a bug in pthread_cond_destroy of Libc (with
Mac
OS X 10.4.10).
Current implementation of pthread_cond_destroy does not check if
sigspending==0. Thus if pthread_cond_destroy is called from a
thread
other than that called pthread_cond_signal, the destructor may
return
0 even if pthread_cond_signal is still in work (i.e. sigspending !=
0), leading to memory corruption or an infinite loop in
pthread_cond_signal.
For example, in the following code, thread B would sometimes read
from
and/or write to freed memory.
Thread A:
pthread_cond_wait(cond, &mutex);
while ((err = pthread_cond_destroy(cond)) != 0) {
assert(err == EBUSY);
usleep(1);
}
free(cond);
Thread B:
pthread_cond_signal(global_cond);
Note that the problem only arises when thread B does not lock the
same
mutex as thread A when calling thread A (this is not a
requirement in
POSIX threads).
Attached to this mail is a code that would reproduce this bug. It
sends and receives pthread_cond_signals and increment a counter.
It compiled without any compile time defines, the program prints
the
counter incrementing infinitely.
But if compiled with -DCLEAR_MEM -DSIGNAL_WO_LOCK it would suddenly
stop due to memory corruption.
Or if compiled with -DAPPLE_TEST -DSIGNAL_WO_LOCK it would check
the
value of sispending and print an assertion failure.
To reproduce the bug with the attached code, a dual processor
system
might be a requirement.
--
Kazuho Oku
<thtest.c> _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
--
Kazuho Oku
--
Kazuho Oku
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden