Debugging

You can debug your CGI using your current debugging tools since the CGIs are written in C/C++.

Sapphire/Web offers several aids to debugging. When debugging a CGI, the CGI is run from the project directory at the UNIX command line or from within the debugger. The debugger run is xxgdb which uses gdb. Both of these are free, the latter from gnu. The steps described use these tools.

To debug a CGI which is processing an Anchor Activator, you need to get the query string. The first way to get this is to look at the HTML source for the Calling Anchor and get the part of the HREF after the character ?. For example, if the anchor looks like this:

<A HREF=
"http://cezanne/cgibin/table//table.cgi?FNC=tcreate__Atde
mo_html">
Create Table</A>

then the QUERY_STRING is:

FNC=tcreate__Atdemo_html

A second technique is to set the Project Option, "Print Environment" to True. Rebuild your CGI. Click on the Calling Anchor. In the resulting HTML source get the value of the QUERY_STRING environment. Now to use the QUERY_STRING value do the following. Start the debugger with your CGI.

xxgdb table.cgi

where table.CGI is the name of your CGI. Then break points are set. Start the CGI in the debugger using the QUERY_STRING as:

run table.cgi FNC=tcreate__Atdemo_html

where the last parameter is the QUERY_STRING. You may need to perform shell escaping depending on content. If you also want to set up the environment to try to match what the CGI will see when launched from http, you will need to capture the environment. If you already set "Print Environment" as described previously, then you can grab the entire environment from the returned HTML source, and paste it into a file, e.g. ENV. To use that file, start the CGI in the debugger with

run table.cgi FNC=tcreate__Atdemo_html -env ENV

The order of arguments is important.

You can also use Sapphire/Web to capture the IP address of the machine which is accessing your database by using a NULL binding, and passing the value of the IP address in via SaRegisterStringSite. To do this, make a NULL binding from the HTML page that will call your CGI to the HTML page that will return your results. Edit the Activator Code for that binding as follows:

   /* In the "#include, #defines, globals, etc." box */
       #include "SaRnHtml.h"
       char *cp;
   /* In the "Before Object Binding Execution Code" box */
       cp = getenv("REMOTE_ADDR");
   /* In the "After Object Binding Execution Code" box */
       SaRegisterStringSite(NULL, "DataDropSite", cp);

where "DataDropSite" is the name of your data drop site.

Of course there are still several differences with the debug run and the real CGI:

The user for the real CGI is usually "nobody". In the debugger it's you. You may be fooled by permissions on files and directories.
The debugger CGI has other environment variables that the real CGI does not.
Unless the HTML and CGI bin directories are mounted, the debug CGI will run in the starting directory.

To debug form-activated CGIs you need to do the following:

: 1. Set the Project Option, Print Form Args to True.
: 2. Rebuild your CGI.
: 3. Fill in and activate the Calling Form.
: 4. In the resulting HTML source get the form arguments, and paste these into a file, e.g. ARGS, and use that file to start the CGI in the debugger with:

	run table.cgi -debug ARGS

: You can also use the environment, getting it as described above, with:

	run table.cgi -debug ARGS -env ENV

: or

	run table.cgi -env ENV -debug ARGS

: Note: The environment and argument information printed out are HTML-compatible strings and may need some "decoding".

You also can get more debug information from the real CGI using a code purification tool, such as Purify. Link the CGI with this tool and run the purified version. Then look at the resulting log file. Permissions must be set for the user "nobody" to write this log file.

[Top] [Prev] [Next] [Bottom] [Contents]

info@bluestone.com