site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rISoobAVT+IwuOajVNo1XblYc0ZoQu7GfRfSWeWoaPc=; b=IHYl6C13IOWzjZMMDPGpEkc3+CNWAdKOZ9TJuCbofAWRc713lueJ9uO+TGY9wNnZCexbo276Sh1CimIaQr6DHd0ncUQFwCR9TWlFCCWbVX4FbVD25H2Cax7JtMGaIdr6odBVpEk3eKiVIPkZU6RG2P6Dyb1T8/z7WGHpXVGk3zQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sAX9z2HEIzoH3qIu7eqbsqNpXBwCKjSepk6TGc0HXMGz5TBtuWAOAtUKPrZZQs+JvRiX6dFwCfLqwA5EeJcBxGB1WjdcurKS8DqbtzQp6qfy49lshN+4x/oLRjNlKcGcTv+2qyPLPqrYykuyIRyQLnMzHvQ9zV+kNz4N9rRl5hM= 2008/1/9, Jim Magee <jmagee@apple.com>:

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. That 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 would be the case in my example. My understanding is that there is the case in the Mac OS version of pthread 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/jmagee%40apple.com

This email sent to jmagee@apple.com

PS. I think I have initially responded to Jim only and am re-posting the mail with slight modifications. -- Kazuho Oku _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com