From owner-freebsd-threads@FreeBSD.ORG Fri Nov 21 02:17:19 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1128F16A4CE for ; Fri, 21 Nov 2003 02:17:19 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 570AB43FD7 for ; Fri, 21 Nov 2003 02:16:15 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id hALAFCEG004800; Fri, 21 Nov 2003 02:15:12 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) hALAFC20092718; Fri, 21 Nov 2003 02:15:12 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.10/8.12.10/Submit) id hALADuGp092706; Fri, 21 Nov 2003 02:13:56 -0800 (PST) (envelope-from marcel) Date: Fri, 21 Nov 2003 02:13:56 -0800 From: Marcel Moolenaar To: Daniel Eischen Message-ID: <20031121101356.GA92329@athlon.pn.xcllnt.net> References: <20031117014620.GB61716@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i cc: David Xu cc: threads@freebsd.org Subject: Re: KSE/ia64 broken X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2003 10:17:19 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. 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? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kse.diff" Index: thr_kern.c =================================================================== RCS file: /home/ncvs/src/lib/libpthread/thread/thr_kern.c,v retrieving revision 1.102 diff -u -r1.102 thr_kern.c --- thr_kern.c 9 Nov 2003 00:37:14 -0000 1.102 +++ thr_kern.c 21 Nov 2003 09:31:22 -0000 @@ -2443,6 +2443,8 @@ free(thread); thread = NULL; } else { + _thread_printf(1, "XXX:%s: thread=%p, tcb=%p\n", + __func__, thread, thread->tcb); /* * Initialize thread locking. * Lock initializing needs malloc, so don't --nFreZHaLTZJo0R7j--