nexmon – Blame information for rev 1
?pathlinks?
Rev | Author | Line No. | Line |
---|---|---|---|
1 | office | 1 | <?xml version="1.0"?> |
2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" |
||
3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ |
||
4 | ]> |
||
5 | <refentry id="glib-running"> |
||
6 | <refmeta> |
||
7 | <refentrytitle>Running GLib Applications</refentrytitle> |
||
8 | <manvolnum>3</manvolnum> |
||
9 | <refmiscinfo>GLib Library</refmiscinfo> |
||
10 | </refmeta> |
||
11 | |||
12 | <refnamediv> |
||
13 | <refname>Running GLib Applications</refname> |
||
14 | <refpurpose> |
||
15 | How to run and debug your GLib application |
||
16 | </refpurpose> |
||
17 | </refnamediv> |
||
18 | |||
19 | <refsect1> |
||
20 | <title>Running and debugging GLib Applications</title> |
||
21 | |||
22 | <refsect2> |
||
23 | <title>Environment variables</title> |
||
24 | |||
25 | <para> |
||
26 | The runtime behaviour of GLib applications can be influenced by a |
||
27 | number of environment variables. |
||
28 | </para> |
||
29 | |||
30 | <formalpara> |
||
31 | <title>Standard variables</title> |
||
32 | |||
33 | <para> |
||
34 | GLib reads standard environment variables like <envar>LANG</envar>, |
||
35 | <envar>PATH</envar>, <envar>HOME</envar>, <envar>TMPDIR</envar>, |
||
36 | <envar>TZ</envar> and <envar>LOGNAME</envar>. |
||
37 | </para> |
||
38 | </formalpara> |
||
39 | |||
40 | <formalpara> |
||
41 | <title>XDG directories</title> |
||
42 | |||
43 | <para> |
||
44 | GLib consults the environment variables <envar>XDG_DATA_HOME</envar>, |
||
45 | <envar>XDG_DATA_DIRS</envar>, <envar>XDG_CONFIG_HOME</envar>, |
||
46 | <envar>XDG_CONFIG_DIRS</envar>, <envar>XDG_CACHE_HOME</envar> and |
||
47 | <envar>XDG_RUNTIME_DIR</envar> for the various XDG directories. |
||
48 | For more information, see the <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG basedir spec</ulink>. |
||
49 | </para> |
||
50 | </formalpara> |
||
51 | |||
52 | <formalpara id="G_FILENAME_ENCODING"> |
||
53 | <title><envar>G_FILENAME_ENCODING</envar></title> |
||
54 | |||
55 | <para> |
||
56 | This environment variable can be set to a comma-separated list of character |
||
57 | set names. GLib assumes that filenames are encoded in the first character |
||
58 | set from that list rather than in UTF-8. The special token "@locale" can be |
||
59 | used to specify the character set for the current locale. |
||
60 | </para> |
||
61 | </formalpara> |
||
62 | |||
63 | <formalpara id="G_BROKEN_FILENAMES"> |
||
64 | <title><envar>G_BROKEN_FILENAMES</envar></title> |
||
65 | |||
66 | <para> |
||
67 | If this environment variable is set, GLib assumes that filenames are in |
||
68 | the locale encoding rather than in UTF-8. G_FILENAME_ENCODING takes |
||
69 | priority over G_BROKEN_FILENAMES. |
||
70 | </para> |
||
71 | </formalpara> |
||
72 | |||
73 | <formalpara id="G_MESSAGES_PREFIXED"> |
||
74 | <title><envar>G_MESSAGES_PREFIXED</envar></title> |
||
75 | |||
76 | <para> |
||
77 | A list of log levels for which messages should be prefixed by the |
||
78 | program name and PID of the application. The default is to prefix |
||
79 | everything except <literal>G_LOG_LEVEL_MESSAGE</literal> and |
||
80 | <literal>G_LOG_LEVEL_INFO</literal>. |
||
81 | The possible values are |
||
82 | <literal>error</literal>, |
||
83 | <literal>warning</literal>, |
||
84 | <literal>critical</literal>, |
||
85 | <literal>message</literal>, |
||
86 | <literal>info</literal> and |
||
87 | <literal>debug</literal>. |
||
88 | You can also use the special values |
||
89 | <literal>all</literal> and |
||
90 | <literal>help</literal>. |
||
91 | </para> |
||
92 | <para> |
||
93 | This environment variable only affects the default log handler, |
||
94 | g_log_default_handler(). |
||
95 | </para> |
||
96 | </formalpara> |
||
97 | |||
98 | <formalpara id="G_MESSAGES_DEBUG"> |
||
99 | <title><envar>G_MESSAGES_DEBUG</envar></title> |
||
100 | |||
101 | <para> |
||
102 | A space-separated list of log domains for which informational |
||
103 | and debug messages should be printed. By default, these |
||
104 | messages are not printed. |
||
105 | </para> |
||
106 | <para> |
||
107 | You can also use the special value <literal>all</literal>. |
||
108 | </para> |
||
109 | <para> |
||
110 | This environment variable only affects the default log handler, |
||
111 | g_log_default_handler(). |
||
112 | </para> |
||
113 | </formalpara> |
||
114 | |||
115 | <formalpara id="G-DEBUG:CAPS"> |
||
116 | <title><envar>G_DEBUG</envar></title> |
||
117 | |||
118 | <para> |
||
119 | This environment variable can be set to a list of debug options, |
||
120 | which cause GLib to print out different types of debugging information. |
||
121 | <variablelist> |
||
122 | <varlistentry> |
||
123 | <term>fatal-warnings</term> |
||
124 | <listitem><para>Causes GLib to abort the program at the first call |
||
125 | to g_warning() or g_critical().</para> |
||
126 | </listitem> |
||
127 | </varlistentry> |
||
128 | <varlistentry> |
||
129 | <term>fatal-criticals</term> |
||
130 | <listitem><para>Causes GLib to abort the program at the first call |
||
131 | to g_critical().</para> |
||
132 | </listitem> |
||
133 | </varlistentry> |
||
134 | <varlistentry> |
||
135 | <term>gc-friendly</term> |
||
136 | <listitem><para>Newly allocated memory that isn't directly initialized, |
||
137 | as well as memory being freed will be reset to 0. The point here is |
||
138 | to allow memory checkers and similar programs that use Boehm GC alike |
||
139 | algorithms to produce more accurate results.</para> |
||
140 | </listitem> |
||
141 | </varlistentry> |
||
142 | <varlistentry> |
||
143 | <term>resident-modules</term> |
||
144 | <listitem><para>All modules loaded by GModule will be made resident. |
||
145 | This can be useful for tracking memory leaks in modules which are |
||
146 | later unloaded; but it can also hide bugs where code is accessed |
||
147 | after the module would have normally been unloaded.</para> |
||
148 | </listitem> |
||
149 | </varlistentry> |
||
150 | <varlistentry> |
||
151 | <term>bind-now-modules</term> |
||
152 | <listitem><para>All modules loaded by GModule will bind their symbols |
||
153 | at load time, even when the code uses %G_MODULE_BIND_LAZY.</para> |
||
154 | </listitem> |
||
155 | </varlistentry> |
||
156 | </variablelist> |
||
157 | The special value all can be used to turn on all debug options. |
||
158 | The special value help can be used to print all available options. |
||
159 | </para> |
||
160 | </formalpara> |
||
161 | |||
162 | <formalpara id="G_SLICE"> |
||
163 | <title><envar>G_SLICE</envar></title> |
||
164 | |||
165 | <para> |
||
166 | This environment variable allows reconfiguration of the GSlice |
||
167 | memory allocator. |
||
168 | <variablelist> |
||
169 | <varlistentry> |
||
170 | <term>always-malloc</term> |
||
171 | <listitem><para>This will cause all slices allocated through |
||
172 | g_slice_alloc() and released by g_slice_free1() to be actually |
||
173 | allocated via direct calls to g_malloc() and g_free(). |
||
174 | This is most useful for memory checkers and similar programs that |
||
175 | use Boehm GC alike algorithms to produce more accurate results. |
||
176 | It can also be in conjunction with debugging features of the system's |
||
177 | malloc() implementation such as glibc's MALLOC_CHECK_=2 to debug |
||
178 | erroneous slice allocation code, although |
||
179 | <literal>debug-blocks</literal> is usually a better suited debugging |
||
180 | tool.</para> |
||
181 | </listitem> |
||
182 | </varlistentry> |
||
183 | <varlistentry> |
||
184 | <term>debug-blocks</term> |
||
185 | <listitem><para>Using this option (present since GLib 2.13) engages |
||
186 | extra code which performs sanity checks on the released memory |
||
187 | slices. Invalid slice addresses or slice sizes will be reported and |
||
188 | lead to a program halt. This option is for debugging scenarios. |
||
189 | In particular, client packages sporting their own test suite should |
||
190 | <emphasis>always enable this option when running tests</emphasis>. |
||
191 | Global slice validation is ensured by storing size and address |
||
192 | information for each allocated chunk, and maintaining a global |
||
193 | hash table of that data. That way, multi-thread scalability is |
||
194 | given up, and memory consumption is increased. However, the |
||
195 | resulting code usually performs acceptably well, possibly better |
||
196 | than with comparable memory checking carried out using external |
||
197 | tools.</para> |
||
198 | <para>An example of a memory corruption scenario that cannot be |
||
199 | reproduced with <literal>G_SLICE=always-malloc</literal>, but will |
||
200 | be caught by <literal>G_SLICE=debug-blocks</literal> is as follows: |
||
201 | <programlisting> |
||
202 | void *slist = g_slist_alloc (); /* void* gives up type-safety */ |
||
203 | g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */ |
||
204 | </programlisting></para> |
||
205 | </listitem> |
||
206 | </varlistentry> |
||
207 | </variablelist> |
||
208 | The special value all can be used to turn on all options. |
||
209 | The special value help can be used to print all available options. |
||
210 | </para> |
||
211 | </formalpara> |
||
212 | |||
213 | <formalpara id="G_RANDOM_VERSION"> |
||
214 | <title><envar>G_RANDOM_VERSION</envar></title> |
||
215 | |||
216 | <para> |
||
217 | If this environment variable is set to '2.0', the outdated |
||
218 | pseudo-random number seeding and generation algorithms from |
||
219 | GLib 2.0 are used instead of the newer, better ones. You should |
||
220 | only set this variable if you have sequences of numbers that were |
||
221 | generated with Glib 2.0 that you need to reproduce exactly. |
||
222 | </para> |
||
223 | </formalpara> |
||
224 | |||
225 | <formalpara id="LIBCHARSET_ALIAS_DIR"> |
||
226 | <title><envar>LIBCHARSET_ALIAS_DIR</envar></title> |
||
227 | |||
228 | <para> |
||
229 | Allows to specify a nonstandard location for the |
||
230 | <filename>charset.aliases</filename> file that is used by the |
||
231 | character set conversion routines. The default location is the |
||
232 | <replaceable>libdir</replaceable> specified at compilation time. |
||
233 | </para> |
||
234 | </formalpara> |
||
235 | |||
236 | <formalpara id="TZDIR"> |
||
237 | <title><envar>TZDIR</envar></title> |
||
238 | |||
239 | <para> |
||
240 | Allows to specify a nonstandard location for the timezone data files |
||
241 | that are used by the #GDateTime API. The default location is under |
||
242 | <filename>/usr/share/zoneinfo</filename>. For more information, |
||
243 | also look at the <command>tzset</command> manual page. |
||
244 | </para> |
||
245 | </formalpara> |
||
246 | |||
247 | </refsect2> |
||
248 | |||
249 | <refsect2 id="setlocale"> |
||
250 | <title>Locale</title> |
||
251 | |||
252 | <para> |
||
253 | A number of interfaces in GLib depend on the current locale in which |
||
254 | an application is running. Therefore, most GLib-using applications should |
||
255 | call <function>setlocale (LC_ALL, "")</function> to set up the current |
||
256 | locale. |
||
257 | </para> |
||
258 | |||
259 | <para> |
||
260 | On Windows, in a C program there are several locale concepts |
||
261 | that not necessarily are synchronized. On one hand, there is the |
||
262 | system default ANSI code-page, which determines what encoding is used |
||
263 | for file names handled by the C library's functions and the Win32 |
||
264 | API. (We are talking about the "narrow" functions here that take |
||
265 | character pointers, not the "wide" ones.) |
||
266 | </para> |
||
267 | |||
268 | <para> |
||
269 | On the other hand, there is the C library's current locale. The |
||
270 | character set (code-page) used by that is not necessarily the same as |
||
271 | the system default ANSI code-page. Strings in this character set are |
||
272 | returned by functions like <function>strftime()</function>. |
||
273 | </para> |
||
274 | |||
275 | </refsect2> |
||
276 | |||
277 | <para> |
||
278 | glib ships with a set of python macros for the gdb debugger. These includes pretty |
||
279 | printers for lists, hashtables and gobject types. It also has a backtrace filter |
||
280 | that makes backtraces with signal emissions easier to read. |
||
281 | </para> |
||
282 | |||
283 | <para> |
||
284 | To use this you need a recent enough gdb that supports python scripting. Gdb 7.0 |
||
285 | should be recent enough, but branches of the "archer" gdb tree as used in Fedora 11 |
||
286 | and Fedora 12 should work too. You then need to install glib in the same prefix as |
||
287 | gdb so that the python gdb autoloaded files get installed in the right place for |
||
288 | gdb to pick up. |
||
289 | </para> |
||
290 | |||
291 | <para> |
||
292 | General pretty printing should just happen without having to do anything special. |
||
293 | To get the signal emission filtered backtrace you must use the "new-backtrace" command |
||
294 | instead of the standard one. |
||
295 | </para> |
||
296 | |||
297 | <para> |
||
298 | There is also a new command called gforeach that can be used to apply a command |
||
299 | on each item in a list. E.g. you can do |
||
300 | <programlisting> |
||
301 | gforeach i in some_list_variable: print *(GtkWidget *)l |
||
302 | </programlisting> |
||
303 | Which would print the contents of each widget in a list of widgets. |
||
304 | </para> |
||
305 | |||
306 | <refsect2> |
||
307 | <title>SystemTap</title> |
||
308 | |||
309 | <para> |
||
310 | <ulink url="http://sourceware.org/systemtap/">SystemTap</ulink> is a dynamic whole-system |
||
311 | analysis toolkit. GLib ships with a file <filename>glib.stp</filename> which defines a |
||
312 | set of probe points, which you can hook into with custom SystemTap scripts. |
||
313 | See the files <filename>glib.stp</filename> and <filename>gobject.stp</filename> which |
||
314 | are in your shared SystemTap scripts directory. |
||
315 | </para> |
||
316 | |||
317 | </refsect2> |
||
318 | |||
319 | <refsect2> |
||
320 | <title>Memory statistics</title> |
||
321 | |||
322 | <para> |
||
323 | g_mem_profile() will output a summary g_malloc() memory usage, if memory |
||
324 | profiling has been enabled by calling |
||
325 | <literal>g_mem_set_vtable (glib_mem_profiler_table)</literal> upon startup. |
||
326 | </para> |
||
327 | |||
328 | <para> |
||
329 | If GLib has been configured with <option>--enable-debug=yes</option>, |
||
330 | then g_slice_debug_tree_statistics() can be called in a debugger to |
||
331 | output details about the memory usage of the slice allocator. |
||
332 | </para> |
||
333 | |||
334 | </refsect2> |
||
335 | </refsect1> |
||
336 | </refentry> |