Debugging

Tracing and Backtrace file

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

gg -e 3

Copied!

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

gg -t 5

Copied!

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

Output from Gliimly application without web server

Use gg (see -r option) to send a request from command line, and receive reply from your services. This is useful in debugging issues and automating tests.

Issues in starting mgrg

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

/var/lib/gg/app_name/mgrglog/log

Copied!

Web server error log

If you are using a web server as a reverse proxy, check its error log, which would store the error messages emitted. Typically, such files are in the following location:

/var/log/<web server>

Copied!

(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 gg). Do not use "--debug" in any other case, because performance will be considerably affected.

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

ps -ef|grep app_name.srvc

Copied!

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 gg).

Use gdb to load your program:

sudo gdb /var/lib/gg/bld/app_name/app_name.srvc

Copied!

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

att <PID>

Copied!

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

br <request name>

Copied!

or in general Gliimly request dispatcher:

br gg_dispatch_request

Copied!

which would handle any request to your application.

Note that by default, gdb will show Gliimly code and you can step through it as you've written it, which is easy to follow and understand.

However, if you wish to step through the underlying C libraries, use "--c-lines" option in gg when making your application. In addition, you can use "--plain-diag" option to see diagnostics for underlying C code alone. These options should be used only if you're trying to debug issues with Gliimly itself, or to find and report a bug in Gliimly.

Debugging version of Gliimly, as well as using "--debug" option to compile, will considerably slow down run-time performance (in some tests about 50-55%); do not use Gliimly build with debugging symbols (see install) nor "--debug" (see gg) in production.