Re: Run away 4GL's

On Thu, 25 Feb 1999, Watson, Paul wrote: >>[cutting] >>>You could verify what's going on by running truss on one of the runaway >>>processes (truss -p $runaway_pid) as root. If I'm right, you'll see a >>>clear pattern in the output running over a repeat cycle of about 15 lines. >> >>There is no repeating pattern just the same line continuously, read stdin > >OK - the repeat cycle is 1 line, and the bug is not related to signal >handling. Most of my previous hypotheses are therefore irrelevant. > >The bug is that zero bytes are being read (the read() call returns either 0 >or -1, doesn't it?), and this is being ignored by the executable. This >problem is supposed to be fixed, too, but maybe it isn't. I forget the >details of the correct fix, but when you get zero bytes from the terminal >in raw mode (so that control-D or equivalent is not being interpreted by >the terminal driver code), there isn't a terminal left and the program >should give up -- but isn't doing so. The return is 0 - oddly reading the documentation indicates >0 is sucess and -1 is an error, no mention of 0 >Even though the signal handling should not be relevant, it would still be >interesting to see what happens to the application to take it out of its >spin cycle - so if you get the opportunity to use truss on a runaway and >then terminate the process by sending a message to the pty, then I'd be >interested to see (an abbreviated version of) the clean up actions, from >the last 5 reads() in a loop to the end, say. truss output read(0, 0x001E58D4, 1) = 0 read(0, 0x001E58D4, 1) = 0 read(0, 0x001E58D4, 1) = 0 ( file cat'd at this point to tty) read(0, 0x001E58D4, 1) (sleeping...) Art - we are not using Pcode The bottom line - its now passed to Informix as a bug Paul Watson