Date: Fri, 21 Nov 2003 20:33:31 +0800 From: David Xu <davidxu@freebsd.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: threads@freebsd.org Subject: Re: KSE/ia64 broken Message-ID: <3FBE061B.3070206@freebsd.org> In-Reply-To: <20031121101356.GA92329@athlon.pn.xcllnt.net> References: <20031117014620.GB61716@dhcp01.pn.xcllnt.net> <Pine.GSO.4.10.10311191627050.15552-100000@pcnet5.pcnet.com> <20031121101356.GA92329@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: >On Wed, Nov 19, 2003 at 04:27:51PM -0500, Daniel Eischen wrote: > > >>>>The returned memory block from malloc() is being used by unknown code, I >>>>don't know >>>>why it occurs, but if you waste a memory block by applying the following >>>>patch for >>>>thr_alloc(), then things work: >>>> >>>> >>>The memory block is clobbered by a ucontext_t. This may be the result >>>of the kernel doing the upcall (though indirectly I would suspect). >>> >>> >>Any more on this. I haven't been able to find anything >>on our end. >> >> > >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 ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FBE061B.3070206>