Date: Tue, 28 Sep 2010 12:20:09 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: svn commit: r213241 - in head: include lib/libthr/thread Message-ID: <201009281220.12278.jkim@FreeBSD.org> In-Reply-To: <201009281202.22555.jkim@FreeBSD.org> References: <201009280457.o8S4vuS9060037@svn.freebsd.org> <201009280931.59163.jhb@freebsd.org> <201009281202.22555.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 September 2010 12:02 pm, Jung-uk Kim wrote: > On Tuesday 28 September 2010 09:31 am, John Baldwin wrote: > > On Tuesday, September 28, 2010 12:57:56 am David Xu wrote: > > > Author: davidxu > > > Date: Tue Sep 28 04:57:56 2010 > > > New Revision: 213241 > > > URL: http://svn.freebsd.org/changeset/base/213241 > > > > > > Log: > > > In current code, statically initialized and destroyed object > > > have same null value, the code can not distinguish between > > > them, to fix the problem, now a destroyed object is assigned to > > > a non-null value, and it will be rejected by some pthread > > > functions. PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP is changed to > > > number 1, so that adaptive mutex can be statically initialized > > > correctly. > > > > Does this fix PR threads/150889 then? > > It seems it does. Unfortunately, it seems to have a regression: %cat test.c #include <pthread.h> #include <stdio.h> static pthread_cond_t static_cond = PTHREAD_COND_INITIALIZER; static pthread_mutex_t static_mutex = PTHREAD_MUTEX_INITIALIZER; int main(void) { // pthread_mutex_lock(&static_mutex); printf("%d\n", pthread_cond_wait(&static_cond, &static_mutex)); pthread_mutex_unlock(&static_mutex); return (0); } %cc -o test test.c -pthread %./test Segmentation fault (core dumped) pthread_cond_wait(3) had to return EPERM here. :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009281220.12278.jkim>