GOLF(2gg)

💖 GOLF(2gg) — the debugging glow-up 💖

okay bestie, you're reading the GOLF manual, section 2gg, straight out of Development. This one's the debugging page. Pull up a chair, grab a strawberry 🍓, and let's get your app ✨diagnosed✨.

---

🎀 NAME 🎀

debugging — Golf documentation (debugging)

---

🌸 DESCRIPTION 🌸

🔥 TRACING AND BACKTRACE FILE

So like, when Golf starts throwing errors at you and you're sitting there like 😭, here's the move: use the -e option of gg and go read the backtrace file. That's where the receipts live, no cap.

Wanna see just the last 3 error messages? Say less:

gg -e 3

You can also drop a trace-run statement to create run-time traces — the location of those files lives in directories, iykyk. And when you need to find the trace files you just wrote to, the -t option of gg is your bestie. For the 5 most recently used trace files:

gg -t 5

Also! Use get-req to grab the trace file location at run-time from inside your application. Very main character of it honestly. 💅

---

🦋 OUTPUT FROM GOLF APPLICATION WITHOUT WEB SERVER

Use gg (peep the -r option) to yeet a request from the command line and get the reply back from your services. This is so useful for debugging issues and automating tests. It's giving efficiency. 👑

---

💀 ISSUES IN STARTING MGRG

mgrg is the one that starts your web application, running as service processes. So if mgrg is acting up, go check out its log. Let's say your application name is app_name (iconic name, love that for you) — the log file is right here:

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

---

🌈 WEB SERVER ERROR LOG

If you're running a web server as a reverse proxy, go check its error log — that's where all the error messages it emits end up. Typically these files live at:

/var/log/<web server>

(for example /var/log/apache2), but lowkey the location may vary — so consult your web server's documentation. Don't come for me, come for the docs. 🙈

---

💜 USING GDB DEBUGGER

Good news, bestie: to use the gdb debugger you don't need to do anything special. Golf itself, plus applications created with Golf, already come with debugging information. Built-in. ✨

And 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

Real talk though — you can control the number of worker processes started, so you can have only a single worker process (or the minimum necessary). That makes attaching to the process that actually processes a request way easier (see gg). So considerate fr fr. 🫶

Now 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 you're attached, you can break in the request you're debugging:

br <request name>

or break in the general Golf request dispatcher:

br gg_dispatch_request

which would handle any request to your application. Any of them. All of them. Slay.

Now, note this: by default, gdb will show Golf code, and you can step through it exactly as you've written it — which is easy to follow and understand. Chef's kiss. 😘

But! If you wish to step through the underlying C libraries, use the --c-lines option in gg when making your application. In addition, you can use the --plain-diag option to see diagnostics for underlying C code alone.

⚠️ Heads up: 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. Not for casual scrolling, bestie. This is surgical. 🔬

---

⭐ SEE ALSO ⭐

• Debugging
• debugging trace-run See all documentation

---

and that's the whole page, babes 🧚

This was GOLF(2gg) from $VERSION, dated $DATE — mwah, go debug something gorgeous. 💖✨🎀