IT452 - Debugging Tips

Main IT452 page

Debugging Tips

You should try all of these before banging your head against the wall.

Use Chrome to debug. Its tools are better. The following assumes Chrome.

Javascript code isn't doing what I want

  1. Look at the Error Console. Right-click your page (anywhere), select "Inspect Elements". Then click the "Console" tab. Are there errors in red? Look at the line number on the error, look in your code to see if you see what is wrong. If there is an error but you can't tell from the code what is wrong, see below.

There is a Javascript error, but I don't know what it means

  1. Use alert statements. You know what line the error occurs on, so put an alert("debug here") statement immediately before that line to print something useful. Most likely this means printing a variable to see what its value is.

No Javascript errors, but my DOM manipulation code still doesn't work

  1. Use the "Elements" tab in the debugging console. Right-click your page (anywhere), select "Inspect Elements". This brings up the Elements and you can navigate your page's DOM tree. You can find everything in there, so if you think your code should have created a <p> tag, try to find it! It may have appeared in a different place in your DOM than you expect, and this will help you discover that.

No Javascript errors, but Ajax still doesn't work (also known as "Network help")

  1. Look at Network tab. In Chrome, open the debugging panel and click Network. Leaving this open, interact with your web page so that your Ajax call would normally be made if it was working how you thought it should. Did a message show up in the Network panel? If no, it is not Perl's fault, it is something in your Javascript's ajax code. If yes, go to (2).
  2. Click the Perl script in Network tab. If Ajax sent the request, it showed up in the Network tab. Click your perl script there. It will now show on the right your "Headers" and your "Response". Look in the Headers and see if everything looks normal. A "Status Code" of "200 OK" means your Perl was called and it returned something valid. You also want to look at the first line, "Request URL" and lower down, "Query String Parameters" to see what your ajax code sent to your script. If that looks ok, click the "Response" tab. This shows you exactly what your Perl script returned to Ajax. If it is blank, then it returned nothing.
  3. Type your Perl script into the navbar. Try calling your Perl script directly. Type it into your browser! What happens? If it displays exactly what you expect, the problem is probably in your javascript (now put an alert statement in the function that ajax should call on return). If you get a server error from the navbar use, see "Perl is not working" below.

Catching exceptions in Chrome.

A very useful feature is to tell Chrome's Javascript debugger to stop whenever it encounters any exception (roughly, any kind of JavaScript error). Turning this on is highly recommended!
  1. Right-click inside Chrome (on the page) and pick "Inspect element"
  2. Click on the "Sources" tab (this may be the word Sources, or may be an icon).
  3. There should be a small pane in the bottom-right of your screen. Near the top of this are some icons that control debugging (used to Run, Pause, Step etc.).
  4. Hover over each icon to find the one that talks about pausing on exceptions. Click on it until when you hover it says something like "Pause on all exceptions" (the color will probably change). The picture below shows what you are looking for (this shows BEFORE clicking):
  5. Once you do this, Chrome will catch exceptions in the debugger. For instance, if something goes wrong in JavaScript, it should pop-up the debugger and show you the line number where the error occurred. You will still have to examine the line and the exception to figure out what is wrong.
  6. This is very useful, so remember this! You will probably have to do this again when you restart Chrome.

Perl is not working (how to debug Perl).

  1. Run Perl via the webserver. In your web browser, use a URL like this: http://intranet.cs.usna.edu/~mXXXXXX/it452/Lab21/query.pl?user=joe&page=20
  2. Run Perl from ssh. If you can't run successfully from the web browser, it is time for real debugging. ssh into the webserver (intranet.cs.usna.edu). You can use putty or any other ssh client. 'cd' into your public_html/it452/LabXX directory. Now run your perl script. If no arguments are needed, run like this:
     
        ./query.pl 
    
    or if arguments are needed, type something like this:
     
        ./query.pl "user=joe&page=20"
    
    Examine the output. Were there errors??? (see below)
  3. /usr/bin/perl^M: bad interpreter: No such file or directory: Did you see this error? Anytime you see a ^M character, that means your file is in DOS-mode and has carriage return characters that unix doesn't like. You need to change from DOS-mode to UNIX (see details below on Perl files / line endings).
  4. /usr/local/bin/perl: bad interpreter: No such file or directory: The first line of your script is pointing to the wrong perl location. Make sure it is "/usr/bin/perl".
  5. Global symbol "$databaseHandle" requires explicit package name at ./allResults.pl line 11: This usually means you are declaring a variable without using the "my" specifier. Make sure it is "my $var =" and not just "$var =".
  6. Permission denied. Your file permissions are just set incorrectly. "chmod a+rx " to turn them on. Try running it again.
  7. Perl runs from ssh, and even outputs with no errors.: Great! You are almost there. This is probably a problem with (a) permissions (see above) or (b) the header that you are printing first in your script. Remember, you need a header to tell the web browser what type of text you are outputting. If you are printing XML out, the very first print statement should be:
    print( "Content-type: text/xml; charset=UTF-8\n\n");
    If you are printing just text (no XML or HTML), the very first print statement should be:
    print( "Content-type: text/plain; charset=UTF-8\n\n");

Creating Perl files / "line endings"

  1. VERY IMPORTANT: You are likely editing your Perl files on a Windows machine. On Windows, files are usually save in "DOS" mode, which means each line ending is actually two characters (CR/LF). On Unix, only one character is used, and our Unix-based web server will fail on any files saved in Windows mode. For this reason:



































































End