From owner-freebsd-current Fri Oct 25 15:25:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA25795 for current-outgoing; Fri, 25 Oct 1996 15:25:10 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA25744 for ; Fri, 25 Oct 1996 15:25:02 -0700 (PDT) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id NAA17081 for ; Fri, 25 Oct 1996 13:41:13 -0700 (PDT) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.7.6/8.6.9) id GAA28193; Sat, 26 Oct 1996 06:39:38 +1000 (EST) Message-Id: <199610252039.GAA28193@sdev.usn.blaze.net.au> Date: Sat, 26 Oct 1996 06:39:38 +1000 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: ejc@gargoyle.bazzle.com (Eric J. Chet) Cc: freebsd-current@FreeBSD.ORG Subject: Re: -current as of 10/23/96 References: X-Mailer: Mutt 0.48.1 Mime-Version: 1.0 In-Reply-To: ; from Eric J. Chet on Oct 24, 1996 20:16:37 -0400 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Eric J. Chet writes: > Make world as of last night 10/23/96. Can't login using pdksh > it dumps with sig 11, csh and tcsh are fine. I rebuilt ksh same result. > It only dumps at login, works fine from another shell. I had the same result, but since I was busy on something else I just changed shell and thought I'd get back to it when I had time to download the pdksh sources again. However, since you've done most of the work already: > Program terminated with signal 11, Segmentation fault. > #0 shf_close (shf=0xd0d0d0d0) at shf.c:203 > 203 if (shf->fd >= 0) { Do you happen to have /etc/malloc.conf symlinked to 'AD'? (BTW, this has been a *wonderful* help in debugging things I previously never realised had problems over the last few days :-)). If so, then the pattern 0xd0d0d0d0 means that it is an uninitialised value or a variable that previously existed in memory that has been subsequently freed. It is more likely you'll discover how this happens in frame 2: > #2 0x16397 in main (argc=1, argv=0xefbfde54) at main.c:359 Somewhere above there. To point out the obvious, this most likely a bug in pdksh. :) The most likely scenario is something like this: free(xyz); shf_close(xyz->shf); Or perhaps the programmer is as not initialising memory after allocating it. As I said, I haven't looked yet. If you come across the fix, be sure to cc me the patch. :) Hope this helps, David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-791-9547 Data/BBS +61-3-792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn