From owner-freebsd-threads@FreeBSD.ORG Mon Aug 11 07:22:55 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 2911537B401 for ; Mon, 11 Aug 2003 07:22:55 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82DC243F85 for ; Mon, 11 Aug 2003 07:22:54 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h7BEMouN014004; Mon, 11 Aug 2003 10:22:50 -0400 (EDT) Date: Mon, 11 Aug 2003 10:22:50 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20030811001030.GA27859@dhcp42.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 14:22:55 -0000 On Sun, 10 Aug 2003, Marcel Moolenaar wrote: > Gang, > > There seems to be a bug in libkse where we dereference the thread > pointer in situations where it's NULL. I suspect this bug is > specific to platforms that have per-thread thread pointers. I > have some rough gdb(1) support to help out with the analysis: _thr_sig_add() does look at the current thread but it doesn't dereference it. I think it's OK for it to be null. Is it possible that _tp (which points to the tcb) isn't set? So that when you dereference it you get the error? Is the upcall somehow clearing _tp? > 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: 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? -- Dan Eischen