Date: Thu, 10 Oct 1996 11:13:30 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: current@freebsd.org Subject: 'dead' binary stays 'dead'? Message-ID: <199610100143.LAA16437@genesis.atrad.adelaide.edu.au>
next in thread | raw e-mail | index | archive | help
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? -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610100143.LAA16437>