vely:Debugging

Debugging

Several techniques on debugging Vely applications are discussed here.

Tracing and Backtrace file

To see any errors reported by Vely, use -e option of vv and check backtrace file. For example, to see the last 3 error messages:

vv -e 3

You can use trace-run statement to create run-time traces (see how_vely_works for directory location). To quickly find the location of recently written-to trace files, use -t option of vv, for example for 5 most recently used trace files:

vv -t 5

Use get-req to get the trace file location at run-time from your application.

Output from FastCGI application without web server

Use FastCGI_client to send request and receive reply from your FastCGI server processes from command line. This is useful in debugging issues and automating tests.

Issues in starting vf

vf starts your web application, running as FastCGI processes. If you're having issues with vf, check out its log. Assuming your application name is "app_name", the log file is:

/var/lib/vv/app_name/vflog/log

Web server error log

Check web server's error log, which would store the error messages emitted to the client. Typically, such files are in the following location:

/var/log/<web server>

(for example /var/log/apache2), but the location may vary - consult your web server's documentation.

Using gdb debugger

In order to use gdb debugger, you must make your application with "--debug" flag (see vv). Do not use "--debug" in any other case, because performance will be considerably affected.

Ultimately, you can attach a debugger to a running Vely process. If your application name is "app_name", first find the PID (process ID) of its process(es):

ps -ef|grep app_name.fcgi

Note that you can control the number of worker processes started, and thus have only a single worker process (or the minimum necessary), which will make attaching to the process that actually processes a request easier (see vv).

Use gdb to load your program:

sudo gdb /var/lib/vv/bld/app_name/app_name.fcgi

and then attach to the process (<PID> is the process ID you obtained above):

att <PID>

Once attached, you can break in the request you're debugging:

br <request name>

or in general Vely request dispatcher:

br vely_dispatch_request

which would handle any request to your application.

Error containing "vely_statement_must_be_within_code_block_here"

If you get an error like:

error: ‘_vely_statement_must_be_within_code_block_here_1’ undeclared (first use in this function);

then you are attempting to use a Vely statement in a single-statement implicit block, as in:

if (some condition)
    exec-program ....

Since each Vely statement expands into one or more lines, if a Vely statement is the sole functional code used in an implicit code block, you must place it in an explicit block:

if (some condition)  {
    exec-program ....
}

See example_hello_world for an example in debugging and tracing.