Date: Sat, 30 Aug 2008 11:32:35 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: davidxu@freebsd.org, Andriy Gapon <avg@icyb.net.ua>, freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create Message-ID: <Pine.GSO.4.64.0808301128410.9898@sea.ntplx.net> In-Reply-To: <20080829190506.GA2038@deviant.kiev.zoral.com.ua> References: <48B70A98.5060501@icyb.net.ua> <48B7101E.7060203@icyb.net.ua> <48B71BA6.5040504@icyb.net.ua> <20080829141043.GX2038@deviant.kiev.zoral.com.ua> <48B8052A.6070908@icyb.net.ua> <20080829143645.GY2038@deviant.kiev.zoral.com.ua> <Pine.GSO.4.64.0808291223240.5086@sea.ntplx.net> <20080829190506.GA2038@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Aug 2008, Kostik Belousov wrote: > On Fri, Aug 29, 2008 at 12:25:09PM -0400, Daniel Eischen wrote: >> On Fri, 29 Aug 2008, Kostik Belousov wrote: >> >>> On Fri, Aug 29, 2008 at 05:18:18PM +0300, Andriy Gapon wrote: >>>> >>>> Kostik, thanks! >>>> >>>> on 29/08/2008 17:10 Kostik Belousov said the following: >>>>> I am wondering why did you not fixed it youself with all this >>>>> information. >>>> >>>> I am wondering that myself now :-) >>>> I got bogged in rtld details and simply didn't think about the solution >>>> of doing setthreaded earlier. >>>> >>>> I will try your patch a couple of hours later. >>>> BTW, a forward question - should this patch help in the case of an >>>> exception thrown (and caught) before main(), i.e. in constructors of >>>> static/global objects? >>> If the objects are from the executable, then yes. I do not know about >>> present situation, but some time ago g++ and several other compilers >>> called ctr for global objects from the main() function. Regardeless >>> of this, init for main executable shall be called after init for >>> dependencies is finished. See initlist_add_objects(). >>> >>> On the other hand, ctr calls from linked dso may get fixed in regard >>> of exception throwing, or may not, depending on the relative order of >>> the dso loading against libthr. >>> >>>> >>>>> Anyway, patch below seems to work for me. David may have an opinion on >>>>> the change. >>>>> >>>>> diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c >>>>> index f96bba9..785d610 100644 >>>>> --- a/lib/libthr/thread/thr_init.c >>>>> +++ b/lib/libthr/thread/thr_init.c >>>>> @@ -355,6 +355,9 @@ _libpthread_init(struct pthread *curthread) >>>>> if (_thread_event_mask & TD_CREATE) >>>>> _thr_report_creation(curthread, curthread); >>>>> } >>>>> + >>>>> + if (_thr_isthreaded() == 0) >>>>> + _thr_setthreaded(1); >>>>> } >>>>> >>>>> /* >> >> I think the intent of __isthreaded (and _thr_setthreaded()) was >> to be set if there were more than 1 thread, not to indicate that >> the thread library has been initialized. > > As demonstrated by Andriy' example, we need _thr_rtld_init() be called > before any rtld locks are given chance to be acquired. _thr_rtld_init() > shall be protected from repeated invocation, and _thr_setthreaded() > implements exactly this. > > If calling _thr_setthreaded(1) has not quite right intent, could you, > please, suggest satisfying solution ? I'm not sure I _quite_ understand the problem, but why wouldn't you have the same potential problem with some other library (without libthread)? I'll have to go back and read the beginning of the thread - I just kinda came in at the end. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0808301128410.9898>