1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
.TH GOLF 2gg $VERSION $DATE Development Tools
.SH NAME
debugging \- Golf documentation (debugging)
.SH DESCRIPTION
.LP
.B TRACING AND BACKTRACE FILE
.LP
To see any errors reported by Golf, use -e option of \fBgg\fP and check backtrace file. For example, to see the last 3 error messages:
.RS 4
.EX
gg -e 3
.EE
.RE
You can use \fBtrace-run\fP statement to create run-time traces (see \fBdirectories\fP for directory location). To quickly find the location of recently written-to trace files, use -t option of \fBgg\fP, for example for 5 most recently used trace files:
.RS 4
.EX
gg -t 5
.EE
.RE
Use \fBget-req\fP to get the trace file location at run-time from your application.
.LP
.B OUTPUT FROM GOLF APPLICATION WITHOUT WEB SERVER
.LP
Use \fBgg\fP (see -r option) to send a request from command line, and receive reply from your \fBservice\fPs. This is useful in debugging issues and automating tests.
.LP
.B ISSUES IN STARTING MGRG
.LP
\fBmgrg\fP starts your web application, running as \fBservice\fP processes. If you're having issues with mgrg, check out its log. Assuming your application name is "app_name", the log file is:
.RS 4
.EX
/var/lib/gg/app_name/mgrglog/log
.EE
.RE
.LP
.B WEB SERVER ERROR LOG
.LP
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:
.RS 4
.EX
/var/log/<web server>
.EE
.RE
(for example /var/log/apache2), but the location may vary - consult your web server's documentation.
.LP
.B USING GDB DEBUGGER
.LP
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):
.RS 4
.EX
ps -ef|grep app_name.srvc
.EE
.RE
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 \fBgg\fP).
Use gdb to load your program:
.RS 4
.EX
sudo gdb /var/lib/gg/bld/app_name/app_name.srvc
.EE
.RE
and then attach to the process (<PID> is the process ID you obtained above):
.RS 4
.EX
att <PID>
.EE
.RE
Once attached, you can break in the request you're debugging:
.RS 4
.EX
br <request name>
.EE
.RE
or in general Golf request dispatcher:
.RS 4
.EX
br gg_dispatch_request
.EE
.RE
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 \fBgg\fP 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.
.SH SEE ALSO
Debugging
\fBdebugging\fP
\fBtrace-run\fP
See all
\fBdocumentation\fP
|
