Date: Fri, 21 Nov 2003 09:12:15 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: David Xu <davidxu@freebsd.org> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: KSE/ia64 broken Message-ID: <Pine.GSO.4.10.10311210907140.26146-100000@pcnet5.pcnet.com> In-Reply-To: <3FBE061B.3070206@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Nov 2003, David Xu wrote: > Marcel Moolenaar wrote: > > >Ok. More pieces of the puzzle. If I apply the attached patch (against > >clean sources), I get the following: > > > >itanium% ./foo.bad > >XXX:_thr_alloc: thread=200000000008a000, tcb=2000000000085000 > >XXX:_thr_alloc: thread=2000000000090000, tcb=2000000000090000 > > > >The second _thr_alloc() is screwed up, in that malloc() returns > >the same pointer twice. Hence thread->tcb points to thread itself > >and we're clobbering our thread structure. > > > I saw the same result. > > >Since thr_spinlock.c > >affects the locking of malloc(), we may have a race condition. > >Note that forcing an upcall (by adding a _thread_printf() in the > >code stream) seems to fix it. Does the UTS call malloc when first > >invoked? > > > > > > > No, we never call malloc in such case. I suspect we do not > fully restore thread's context. In kernel, I pass zero as third > parameter to get_mcontext(), is it enough for ia64 ? Well, we do call malloc at library initialization. We malloc initial KSE & thread, locks, and a few other things. But this is before __isthreaded gets set (so the spinlock shouldn't be used). All this is done before the first thread is created. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10311210907140.26146-100000>