in reply to Perl infinite loops!

The browser is a very poor debugging mechanism for CGI simply because it displays nothing about errors unless you are sure to throw in CGI::Carp (which is recommended). Also, if you screw up your headers, you'll have NO idea of what's going on since the web server or browser will end up with some confusing info. In short, 
use CGI;
use CGI::Carp qw/fatalsToBrowser set_message/; #read more about these 
+in the docs link above
alarm($x); #if you wish, though I consider this a quick hack since a h
+eavy server load may actually force your users to wait this long even
+ though there is no infinite loop and still get the info they wanted 
+cut off

[download]
The best solution is to test all CGI beforehand with interactive mode or the debugger ("or" is not a mutually exclusive term- that's "xor" which i would have written if I had meant that). Interactive mode is enabled when you run your CGI script from the command line. This also allows you to easily pass batch CGI params by storing them in a file instead of typing and retyping them in a browser. 
perl cgi.cgi<batch\ file\ with\ \\n\ delimited\ CGI\ params.file

[download]
(Oh geesh! I wrote coed instead of code before- I wonder what I was thinking about....)
AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

Replies are listed 'Best First'.
Re: Re: Perl infinite loops!
by marius (Hermit) on Dec 06, 2000 at 21:57 UTC
    wouldn't a high $x from alarm($x) be worthwhile to look at? If you know what your script does, ideally you know how long it "should" take to run the script, multiply that number by 5 or 10 to account for high server load, and voila.

    I'm curious as to what duration of time the CGI has to run in infi-loop until Apache Zombies the process. I know I've accidentally done that, realized it after about 30-45 seconds, then popped onto the server to SIGKILL the offending perl process.

    -marius
[reply]
      You can use mod_perl or FastCGI to limit cgi runtime, reload progs against memory leaks, limit the number of scripts to be running at any time, load shared objects, preload CGIs (almost like multithreading) and reduce server load. Nowadays, there is no reason to go without such insanely useful Apache mods. My argument against the alarm is that it is A solution but not the best solution. The best is simply to remove the infinite loop or memory leak. If you just throw in an alarm, your script will be killed, perhaps for now reason at all while you searching desperately for the error. Also, this is not portable in the sense that the script may take 10 seconds on computer #1 and 400 seconds on computer #2. This is not good. Throwing in dependence on time is not a good way to ensure user-friendliness. Using the FastCGI mechanism rather than alarm also is smarter, since FastCGI is not script dependent but server dependent and the server isn't likely to be moving around much, thus the same functionality via a better channel.
      AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
        Much agreed with you on your cases here, but frequently someone looking to do this isn't necessarily the admin of the site in question. Or is the admin but can't install new software due to PHB-based/marketroid restrictions. Or the OS in question doesn't support module X. Or the server isn't Apache. I'm assuming (yeah, I know what happens when I do this..) that one of these is the case since silicon39 mentioned that they are still running perl4. So, even if it isn't the best way, as you said, it is a way, and could under some circumstances be the best way.

        -marius
[reply]
        If you know you'll be running on a linux system you could look at getrlimit(2) and setrlimit(2). Assuming that syscall.ph has been correctly h2ph'd you should be able to get this to work from within perl. All you'd need to do then is to set your RLIMIT_CPU to, say, 1 second and your script will be killed by the kernel if it uses more than that.

        The advantage is that it's dependent on how much CPU time your script uses. If the server is busy with some other process your script may run for a lot of wall-clock time, but it will not be killed prematurely.

        The same functionality no doubt exists in other systems, but this is not going to be the most portable implementation in the world.

        We used this to good effect within the suexec wrapper for Apache - at the same time you can prevent memory hogs and fork() bombs, and it applies to all CGI scripts on the server.

[reply]

In Section Seekers of Perl Wisdom