Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uakari.primate.wisc.edu!indri!nic.MR.NET!umn-cs!molenda From: molenda@umn-cs.CS.UMN.EDU (Jason S. Molenda) Newsgroups: gnu.bash.bug Subject: Re: Runaway bash Message-ID: <14839@umn-cs.CS.UMN.EDU> Date: 30 Jul 89 18:47:17 GMT References: <8907261931.AA29540@life.ai.mit.edu> <8907271354.AA29470@aurel.caltech.edu> Distribution: gnu Organization: University of Minnesota, Minneapolis Lines: 55 bfox@AUREL.CALTECH.EDU (Brian Fox) writes: > Date: Wed, 26 Jul 89 15:20:30 -0400 > From: James J Dempsey > I have had over a dozen cases where a bash of mine gets into some very > tight infinite loop and eats up gobs of cpu time. I have tried to get > a core dump, but the only signal they will respond to is SIGKILL, so I > have been unsuccessful. >The only thing that comes to mind is that bash is trying to do some >output, (or read some input) and just keeps trying instead of getting >blocked, or stopped, or something. >If these runaway shells won't respond to SIGTSTP or SIGSTOP, then it is >likely that they are login shells. >If anyone gets more information on this problem, I would like to hear >about it. >Brian I've had this happen to me twice. Once on our Sequent Symmetry S27 running a BSD 4.3-similar OS and once on one of our NeXT cubes. As James noticed, it is not easy to notice when one of these processes start.. If you're using a single-CPU machine it just starts to act very sluggishly. The only difference is that when it happened on the Sequent, the bash process had no controlling terminal (e.g. there was a "?" reported for the terminal by a "ps aux"). When it happened on the NeXT yesterday, there was a controlling terminal (/dev/ttyp1). The only similarity was that I'm pretty sure I was using windowing systems both times (X on the sequent and the NeXT environment on the NeXT), and as we all know occasionally something can go wrong when you're working in one of those windowing environments and the whole thing can crash really quickly... so I'm thinking that maybe the bash programs managed to ignore some kind of signal that they were sent. Both times they appear to be polling for input; they definitely aren't blocked. On the sequent where we have top, I saw the bash process eating up 98% of the CPU time on one of our processors. On the NeXT it had accumulated about 27 minutes of cpu time before I figured it out. ------- Jason Molenda, University of Minnesota, Computer Science dept. Internet: molenda@umn-cs.cs.umn.edu, Uucp: ..!rutgers!umn-cs!molenda Real life: "hey you!"