From owner-freebsd-threads@FreeBSD.ORG Mon Aug 11 08:05:45 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 BF14737B405 for ; Mon, 11 Aug 2003 08:05:43 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 087B043FBF for ; Mon, 11 Aug 2003 08:05:42 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp42.pn.xcllnt.net (dhcp42.pn.xcllnt.net [192.168.4.242]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7BF5fwO073892; Mon, 11 Aug 2003 08:05:41 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp42.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h7BF5fJI000606; Mon, 11 Aug 2003 08:05:41 -0700 (PDT) (envelope-from marcel@dhcp42.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp42.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h7BF5fnu000605; Mon, 11 Aug 2003 08:05:41 -0700 (PDT) (envelope-from marcel) Date: Mon, 11 Aug 2003 08:05:41 -0700 From: Marcel Moolenaar To: Daniel Eischen Message-ID: <20030811150541.GA566@dhcp42.pn.xcllnt.net> References: <20030811001030.GA27859@dhcp42.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: threads@freebsd.org Subject: Re: KSE/ia64: NULL thread pointer in _thr_sig_add() 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: Mon, 11 Aug 2003 15:05:46 -0000 On Mon, Aug 11, 2003 at 10:22:50AM -0400, Daniel Eischen wrote: > > The fault is given on the last instruction if the disassembly > > given above (the thread pointer is r13): > > > > (gdb) info register r13 > > r13 0x0 0 > > (gdb) info register r14 > > r14 0xffffffffffffffe0 -32 > > Right, that's what I was guessing. > > > Q: Shouldn't we call _tcb_set() somewhere in the code stream to make > > sure we have a valid thread pointer? > > Once its set, it should always be set, right? The kernel doesn't > change it, right? I think that's the idea anyways. If you look at > the beginning of _thr_sched_multi(), we handle first time initialization: The kernel creates a new context by virtue of the upcall. Since we established earlier that the thread pointer itself is not part of the context, you cannot assume that the thread pointer is not destroyed. > if ((curkse->k_flags & KF_INITIALIZED) == 0) { > /* Setup this KSEs specific data. */ > _kcb_set(curkse->k_kcb); > > /* Set this before grabbing the context. */ > curkse->k_flags |= KF_INITIALIZED; > } > > That should set it up so that we always have TP set to something > (in this case, it's the fake tcb). But from then on, we rely > on the kernel not to touch it. Are you sure the kernel doesn't > destroy it somehow? I'm positive that the kernel *does* clear _tp. It's by design. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net