jjd@BBN.COM (James J Dempsey) (07/27/89)
I use: Vax 8530, Ultrix 3.0, GCC 1.35, yacc, GNU make 1.35 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. These runaway bashes must come from shells which are in the process of exiting or X windows which are closing or something, because I never notice when they get created. Currently running interactive shells don't go into this state. This wouldn't bother me too much, except we are charged for cpu time on this host. Does anyone have any good ideas about how to debug this problem? Thanks, --Jim--
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/27/89)
Date: Wed, 26 Jul 89 15:20:30 -0400 From: James J Dempsey <jjd@bbn.com> I use: Vax 8530, Ultrix 3.0, GCC 1.35, yacc, GNU make 1.35 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. These runaway bashes must come from shells which are in the process of exiting or X windows which are closing or something, because I never notice when they get created. Currently running interactive shells don't go into this state. Does anyone have any good ideas about how to debug this problem? 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
molenda@umn-cs.CS.UMN.EDU (Jason S. Molenda) (07/31/89)
bfox@AUREL.CALTECH.EDU (Brian Fox) writes: > Date: Wed, 26 Jul 89 15:20:30 -0400 > From: James J Dempsey <jjd@bbn.com> > 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!"
andrewt@watsnew.waterloo.edu (Andrew Thomas) (08/01/89)
I use: Vax 8530, Ultrix 3.0, GCC 1.35, yacc, GNU make 1.35
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.
If anyone gets more information on this problem, I would like to hear
about it.
Brian
I use a uVaxII running Ultrix 2.0. I have had this problem only once,
when the system was very heavily loaded. There was a lot of swapping
going on, so I tried to ^C out of a program only to have bash hang. I
did not manage to find out why, but I thought you would like to have a
confirmation of the problem.
--
Andrew Thomas
andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo
"If a million people do a stupid thing, it's still a stupid thing." - Opus