Debugging
Stack traces
If there is an error in a Golf program (such as trying to access invalid memory, negative status that hasn't been checked etc.), or if there's an internal issue (such as a bug in Golf), a stack trace is created in trace directory (see directories). A single stack trace file is created for each such incident, containing the description of the issue and the file names, function names and line numbers in your source code that led to it. The file names are based on the process-ID of the affected process. There is a limit on how many stack frames Golf will show this way (from the bottom up) - currently it's 150.
View stack traces
To see errors reported by Golf (such as trying to access invalid memory, or crashes; but not those from report-error), use -e option of gg to check the stack trace files, which contain the stack along with file names, function names and line numbers. For example, to see the last 3 errors reported:
gg -e 3

Note that function names are decorated; meaning if a request name has a hyphen ("-"), then it is substituted with an underscore ("_") in a function name; if it has a forward slash ("/"), then it is substituted with a double underscore ("__"). For instance, request "request/sub-request" will be internally represented as function "request__sub_request" and will show up like that in a stack trace.
Output from Golf service without a 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. For instance, the following will issue a request and receive a reply from your service:
 gg -r --req="/my-service" --service --exec

Issues in starting mgrg
mgrg starts your service process(es). If you're having issues with mgrg, check out its log. Assuming your application name is "app-name", the log file is:
$HOME/.golf/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 $HOME/.golf/apps/app-name/.bld/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. Request names are decorated to become function names (see above).

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.

Copyright (c) 2019-2025 Gliim LLC. All contents on this web site is "AS IS" without warranties or guarantees of any kind.