Re: CPU SNACKING WAS: Re: Is it possible to timeout 4GL?

> In <301h0l$g2c@emory.mathcs.emory.edu> paulw@dev.jcdc.eta.gov writes: > > >We had this problem before also on our AIX box, but rather that look to code > >to fix the problem, we used our UNIX knowledge. > >In the users .profile files, rather than just fglgo'ing the program, we > >exec fglgo the program. This lets the kill signals get to through when > >a user disconnects abruptly. This makes sense because most shells trap signals, such as SIGINT, SIGQUIT, SIGHUP, etc, and basically ignore them. By exec'ing the fglgo, the shell is no longer there, and when you disconnect the session, by turning off the terminal, or modem, SIGHUP is sent. I do not know enough about AIX system, but for System V, fglgo should be in same process group along with the shell, unless fglgo used setpgrp(2) to change its process group id. The signal SIGHUP is sent to all processes in the same process group when session is disconnected. I ran a little test using our 4.00 4GL toolkit (fglgo), and found out that it set up a signal handler for SIGHUP. I do not know what the handler is going to do when SIGHUP comes in. But from your experiments, the handler must be doing the right thing by terminating the program. > This article prompted me to try to figure out once more why my program > sometimes starts to eat up all available CPU when connection from the > user breaks in an abnormal way. And finally I think I understand whats > happening: > > Trying to create this condition I ran a query making a report to a unix > file, and while the select was running I turned off the PC/Mac with the > telnet session and watched the 'ps -u user' on the host without trying > to kill them. > > In about the time when query should have finished there was suddenly > created a new process that started to eat CPU. The program had come > to a menu, and the first Item there tried to display the report-file > with 'less', and less was eating CPU. Killing the 'less' process had > the only effect that a new 'less' process was created. SO, obviously > the program was stuck processing the default menu Item. Further testing > of setting the item 'Quit Program' as default had the effect of quitting > the program and erasing all the zombie-processes. > > My sys-adm says it's because Informix; when reading the input; cuts the > activating signal (enter key usually) off the input string without checking > if it's ENTER (1 returned) or an EOF (0 returned) and thus is not able > to raise the exception to quit the program. The symptons you described sounds pretty much like a classical case of a program that reads a character from input, and not recognizing EOF. It would go into an infinite loop, because every time you try to read a character from input, you will always get EOF. Here's a little C program that demonstrates the typical bug: #include <stdio.h> #include <curses.h> main() { chtype ch; char buf[16]; initscr(); noecho(); cbreak(); while (ch = getch()) { if (ch == 'q' || ch == 'Q') break; sprintf(buf, "ch: %d", ch); mvaddstr(12, 0, buf); refresh(); } endwin(); } This one, if you try to run it in the background with &, it will repeatedly try to read char from input, and it will always return -1. The typedef chtype is an int, and it is a standard practice to always declare ch as an int, because you can not tell the difference between -1 and 0xFF if ch is an char. Also, for curses programming, ch can have values greater than 256 when function keys or cursor keys are pressed. This loop will not generate huge amount of output, but the cpu time goes up rapidly. The fix is to add an if statement to check the case when ch equals ERR, and break out of the while loop if it happens. ERR is a preprocessor symbol defined in curses.h, and just happen to have value of -1. Getch() will return ERR if EOF condition existed. The fix: while (ch = getch()) { + if (ch == ERR) + break; > Do others think that this is an Informix problem that they should fix? > Or what do you people think about this? Yes, definitely it is a problem, and it should be fixed. The most prudent thing a program should do when faced with this kind of situation is to abort, the same way program would behave if interrupt key is pressed. > In the hope that someday (while still using Informix) I wont have to worry > about this nuisance anymore. > > Regards, > Gaukur. > gaukur@rhi.hi.is -- ------------------------------------------------------- | Paul T. Pryor | Computer Data Systems, Inc | | (703) 756-8350 Voice/TDD | Falls Church, VA USA | |-------------------------------------------------------| | ptp@fallschurch-acirs2.army.mil [192.86.95.3] | -------------------------------------------------------