Debugging Perl .cgi forms

[nysus]

I'm creating a web-based form but I'm having problems troubleshooting the internal server errors I'm getting. The crux of the problem is this:

When I compile but do not execute the script with a 'perl -cw filename.cgi' command, Perl reports the syntax is 'OK'. And when I run the script from the command line, everything runs just fine, too. Yet, when I access the form with my browser, I get the dreaded "Internal Server Error". Needless to say, it's a real pain trying to find my bugs without a report of the line number is causing the problem.

Question 1: Why is this happening?
Question 2: Is there a workaround to this problem that will help me effectively debug my script?

[dvergin]

It's a little tough to tell what's happening from what you have given us. But here are a few things to check:

- are you using CGI.pm?
- have you printed a proper HTTP header at the top of your output?
- have you successfully produced a "Hello World" page to test your basic approach?
- have you included something like the following near the top of your script to help you trace your errors?

use CGI qw(:standard);
use CGI::Carp;
use CGI::Carp qw(fatalsToBrowser);
local $SIG{__WARN__} = \&Carp::cluck;

If none of this gets you closer to a solution, slim down your script to the minimum that still produces the error and post both the script and the output you get when you run from the command line.

[nysus]

I know the first 3 are all covered. I can get the script working, but I often make errors while modifying the script (I'm new at this) and that's when I get the ISE's.

In regards to your last suggestion:
--I have "use CGI;" at the top of my script
--I have tried using CGI::Carp qw(fatalsToBrowser) but it didn't provide any useful information. I have never tried the other two lines (and don't know what they are) but I will slap them in there and see what happens.

Thanks.

[dvergin]

nysus, is sounds like you are over the big hurdles. This is the point where I just proceed incrementally, adding more material a bit at a time until something goes wrong.

If you get to a point where no amount of staring at the screen brings enlightenment, show us some code and output. We love looking at the real stuff.

But be sure you 'use strict;' and have '-w' in your hashbang line or you will get gently (?) scolded.  ;-)

[nysus]

I slapped those lines in there but get no extra info in my browser.

[converter]

The next time you run into this kind of problem, try CGI::Debug (available from the CPAN). This module seems to do a very fine job of digging out diagnostics that normally cause internal server errors. It can e-mail the diagnostic output to you, which is a neat feature when you don't have permission to read the error logs.

A neat trick that I've used a few times is to wrap a perl compile/syntax check in a shell wrapper, with stderr redirected to stdout:

#!/bin/sh
echo -ne "Content-type: text/plain\n\n"
perl -cw myscript 2>&1
echo -ne "\nsyntax check complete\n"

Configure the shell script and request its URL just as you would any CGI program, and the output from perl -cw will be sent to your client.

This will help you catch problems like a shebang line in your script that specifies the wrong location for the perl executable, as well as the usual assortment of errors that can show up when your script is run in an environment other than the one in which it was written and tested.

Not all servers are configured to allow shell scripts to to talk to the CGI, but when this method works it's very useful.

[tilly]

There are a million and one possible causes. The cause of yours is almost certainly in the server logs. Find them and your life will become easier.

[nysus]

I tried looking at the server logs. Apparenly, the way my web host service works, they don't get updated until like a day later. I'm starting to go slowly insane.

[nysus]

Thanks for all the help on this, everybody. I finally found the problem. It's was this line:

$pwd = $query->param('password');

Apparently, cgi.pm will not allow you to assign a variable to an object (in this case the 'password' object) that has not been created yet. Live and learn. I don't think I'll ever make this mistake again.

[nysus]

P.S.

I solved the problem by checking to see if the password object is defined. Like this:

else {
    if ($query->param('password')) {
        $pwd = $query->param('password');
        if ($pwd eq "suckmydick") {
            $pwd = 1;
                    &form;
                } else {
            &get_password();
        }
    } else {
        &get_password();
    }
}

[indigo]

Hard to say without seeing some of your code.

But here are a some recommendations.
• Check your environment variables
• Check your permissions
• use CGI::Carp qw(fatalsToBrowser);

[sutch]

Ensure that your script is executable by the web server, and that the script is not in DOS format. Both of these have bitten me when working on my web hosting provider's server--where I am unable to view the server logs.

If you also cannot view the logs, try commenting out parts of the script and printing debugging info. This method has helped me sovle problems with troublesome scripts.

[Dr. Mu]

When you access this program from your browser, is it running on the same machine as when you checked it from a command line? If not, are you sure all the modules you need are installed on the web server? The fact that carp isn't returning any useful info makes me wonder if your program died in a use statement before the use CGI::Carp (or in the use CGI::Carp itself!). Also, make sure your shebang line (#!/usr/bin/perl, e.g.) is correct for the system you're running on. Last, as noted above, check your HTTP header. Probably the most common mistake is forgetting to put two endlines after after it, before the HTML.

[nysus]

Here it is by popular demand. I've only put in the code that I changed which broke the script. Look at the password setting to see my level of frustration. :)

#!/usr/bin/perl -w

use strict;
use CGI;
my $query = new CGI;
my $error_message = "";
my $pwd = "";

###############################################
#                          #
# Variable initiation                  #
#                          #
###############################################

my $form_submission_check = "Submit";                    # Set to the 
+name of an object on the form

###############################################
#                          #
# Script program logic                  #
#                          #
###############################################

if ($query->param('cancel')) {   
    &get_password;
} elsif ($query->param('change1')) {
           &change_password();
} elsif ($query->param('change2')) {
    &process_change_password();
} else {
        $pwd = $query->param('password');
        if ($pwd eq "suckmydick") {
        $pwd = 1;
                &form;
        } else {
        &get_password();
    }
}

Thanks.

[Desdinova]

As for seeing the error messages. I know on Netscape Enterprise Server when the CGI fail and returns an Internal Error to the browser the error message is dropped into the web server error log.