Thread View: gnu.bash.bug
4 messages
4 total messages
Started by James J Dempsey
Wed, 26 Jul 1989 19:20
Runaway bash
Author: James J Dempsey
Date: Wed, 26 Jul 1989 19:20
Date: Wed, 26 Jul 1989 19:20
20 lines
1076 bytes
1076 bytes
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--
Runaway bash
Author: Brian Fox
Date: Thu, 27 Jul 1989 13:54
Date: Thu, 27 Jul 1989 13:54
29 lines
1563 bytes
1563 bytes
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
Re: Runaway bash
Author: Jason S. Molenda
Date: Sun, 30 Jul 1989 18:47
Date: Sun, 30 Jul 1989 18:47
55 lines
2712 bytes
2712 bytes
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!"
Re: Runaway bash
Author: Andrew Thomas
Date: Mon, 31 Jul 1989 20:49
Date: Mon, 31 Jul 1989 20:49
23 lines
1533 bytes
1533 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads