The #1 Choice for Web Hosting
Support Forum
How-to Resources
CGI Debugging

How can I debug my CGI scripts without access to the error_log?

The error_log is not made available to users because of its sheer volume and 99% uselessness. However, there is a wide variety of approaches that you can take for debugging your CGI scripts; taken together, they provide much greater power and flexibility than the error_log alone.

Most CGI problems arise when a script will not execute successfully, if at all. If your CGI script won't run at all, the Web server will fail to execute the script at all, and will return "Server Error" or "Permission Denied". If the script does execute, but dies prematurely or generates anything other than standard HTTP headers (such as error messages, for example), the Web server has no choice but to simply give up.

The most common causes of a non-executing script are:

  • Uploading a text CGI script (usually a Perl script) in binary mode from a PC or Macintosh. These systems use a different linefeed convention from Unix, and you must set your FTP client to ASCII or text mode when uploading them. If you do not, the first line of the script will not be correctly read by the system to specify the path to the interpreter, and attempting to execute the script will generate a "File not Found" type of error (which may still be reported as "Server Error").
  • Failing to set the executable bits on the script. This is done with the command chmod 755 filename via Telnet or the more complex quote site chmod 755 filename via FTP (your client may have its own interface for this).
  • Using the wrong URL to reach your script. The URL should resemble http://www.domain.com/cgi-bin/filename
  • An interpreted script with syntax or other parsing errors. The interpreter (usually Perl) must be able to correctly understand all of your script. Although the script is not fully compiled by the interpreter before executing, it is parsed and any syntax errors will be found and reported. To see if this is happening, execute your script from the shell (see below).
  • Run-time errors. If your script executes, but attempts something that fails, it will exit prematurely or generate error messages that interfere with the HTTP headers the Web server is expecting. This is most often caused by insufficient permissions. It may also be caused by programmer error, in which case you should debug your script from the shell (see below).

To execute your script from the shell (reached by Telnet), go to the directory where the script is stored, and execute it with:

cactus~:$ ./scriptname.cgi
The "./" portion is required, because "." is not normally in your path, for security reasons.

If your script fails to execute at all, you may see:

./scriptname.cgi: Command not found.
This can indicate that the script itself was not found (check your directory and filename), or that the interpreter specified in its first line could not be found. If the interpreter was not found, the most common cause is a file corrupted by a binary mode FTP transfer (see above). You may also have an incorrect path. For Perl 5.004_004, use #!/usr/bin/perl. For the Bourne shell, use #!/bin/sh. For any other program or interpreter that you need to find, use the which command.

You may instead see:

./scriptname.cgi: Permission denied.
This indicates that you do not have the correct permissions set. Correct this by typing chmod 755 scriptname.cgi, and trying again.

If the interpreter fails to parse your script, you will see results such as:

syntax error at ./scriptname.cgi line 3, near "while 1"
Execution of ./scriptname.cgi aborted due to compilation errors.
This tells you where to look in your script for a programming error.

You may also receive a system error such as Segmentation fault, Memory fault, Bus error, etc, possibly including the phrase (core dumped). These are usually seen with programming errors in compiled C programs. To work on these, you'll need to enable core dumps (with unlimit coredumpsize or by editing your .cshrc), compile your program with debugging flags (usually -g will suffice), and use a debugger such as gdb. For more information on gdb, please visit its tutorial.

Finally, your program may execute successfully, but immediately complain because it is not being run from the Web, usually because there was no way of getting the CGI query parameters, or other variables such as the remote host address. In this case, you need to simulate the CGI environment from the command line.

Return to How-to Resources

Still need help? E-Mail us!

(888) 855-9321

Sign Up!     Service Plans     Guarantee     Contact Us
12112 Frank Cordova Cir.
El Paso, Texas 79936-4488
Tel./Fax (915) 203-0193