From owner-freebsd-current Thu Oct 10 07:04:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA20218 for current-outgoing; Thu, 10 Oct 1996 07:04:12 -0700 (PDT) Received: from watson.grauel.com (watson.grauel.com [199.233.104.36]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA20212 for ; Thu, 10 Oct 1996 07:04:07 -0700 (PDT) Received: from sparcmill.grauel.com (sparcmill.grauel.com [199.233.104.34]) by watson.grauel.com (8.7.6/8.7.3) with SMTP id JAA08135; Thu, 10 Oct 1996 09:12:59 -0500 (EST) Received: by sparcmill.grauel.com (SMI-8.6/SMI-SVR4) id JAA00429; Thu, 10 Oct 1996 09:04:31 -0500 Date: Thu, 10 Oct 1996 09:04:31 -0500 Message-Id: <199610101404.JAA00429@sparcmill.grauel.com> From: Richard J Kuhns To: Michael Smith Cc: current@FreeBSD.org Subject: 'dead' binary stays 'dead'? In-Reply-To: <199610100143.LAA16437@genesis.atrad.adelaide.edu.au> References: <199610100143.LAA16437@genesis.atrad.adelaide.edu.au> Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith writes: > > Howdy people; (particularly VM people) > > I have a system here that was behaving a little oddly. Overnight it's been > running some software that regularly exec's 'ls' to examine the contents > of a directory (maybe every 20 seconds or so).(1) > > At some point, 'ls' died with a sig11. Rerunning 'ls' caused an immediate > sig11 again. I tried to build another 'ls' so that I could look at the > cores, but no luck 8( > > If it's at all enlightening, I ran the newly-built 'ls', and it worked > (no surprises there); however now the 'old' ls works fine too. > > So I suspect that this has something to do with the 'sticky text' code not > being asked to explicitly forget about programs that have been killed by > signals. I'm aware that this is perhaps a difficult one to resolve > tidily, but I think my scenario may have been : > > - ls loads, a memory error of some sort occurs. > - ls runs, is killed due to memory error. > - ls is rerun, old text is used, is killed again courtesy of memory error. > > Obviously, machines with serious memory errors deserve to loose > infinitely, but this box doesn't fall into that category. It's > survived numerous 'make world' cycles faultlessly, and stands up all > day to the excessive pounding that the physics geeks here subject it > to. > > Comments? Refutations? Merciless laughter? > I'll comment. I just started a `make world' 2 days ago (10/8), which ran just fine (as usual) until it hit one of the gnu libraries during the `make all' phase, where cc1 died with a signal 11. I changed to that directory, did a `make clean', changed back to /usr/src, and restarted with a `make all'. It picked up where it left off, and worked ok for about 2 more minutes, after which it died again. I tried this cycle several more times, and got 3 more sig 11s, 1 sig 6, and one complaint from gcc/cc1 about a "bad INSN". I rebooted, and started the `make all' again -- it finished with no more problems. cc1 didn't _stay_ dead, but it certainly didn't live long after the first occurence of the problem. ASUS motherboard, 120 MH Pentium, 64MB RAM, Buslogic 946c, 2 Barracudas. The `make world' was done on an otherwise idle system, at the console (I wasn't even running X). For what it's worth... -- Richard Kuhns rjk@grauel.com PO Box 6249 Tel: (317)477-6000 \ 100 Sawmill Road x319 Lafayette, IN 47903 (800)489-4891 /