NAME

       debugging - Golf documentation (debugging)

DESCRIPTION

       TRACING AND BACKTRACE FILE

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

           gg -e 3

       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

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

       OUTPUT FROM GOLF 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

       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>

       (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 don't need to do anything special. Golf itself as well as  applications
       created with Golf already come with debugging information.

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

           ps -ef|grep app_name.srvc

       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

       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 Golf request dispatcher:

           br gg_dispatch_request

       which would handle any request to your application.

       Note that by default, gdb will show Golf 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 Golf itself, or to find
       and report a bug in Golf.

SEE ALSO

        Debugging

       debugging trace-run See all documentation

$DATE                                               $VERSION                                           GOLF(2gg)