luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-01-26 22:16:16 +01:00
Code Issues Packages Projects Releases Wiki Activity

Mention g_trap_object_ref

Browse Source 
2006-01-26  Matthias Clasen  <mclasen@redhat.com>

	* gobject/tut_tools.xml: Mention g_trap_object_ref

	* glib/running.sgml: Add g_trap variables to the index.
	Mention conditional breakpoints as an alternative.
This commit is contained in:
Matthias Clasen 2006-01-26 19:28:33 +00:00 committed by Matthias Clasen
parent bd88bf87da
commit 5cb432b56c
3 changed files with 31 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/reference/ChangeLog
View File

@ -1,3 +1,10 @@
2006-01-26 Matthias Clasen <mclasen@redhat.com>
* gobject/tut_tools.xml: Mention g_trap_object_ref
* glib/running.sgml: Add g_trap variables to the index.
Mention conditional breakpoints as an alternative.
Wed Jan 25 17:32:22 2006 Tim Janik <timj@gtk.org>
* glib/tmpl/memory_slices.sgml: link to G_DEBUG/G_SLICE where appropriate.

13
docs/reference/glib/running.sgml
View File

@ -160,6 +160,9 @@ variables like <envar>LANG</envar>, <envar>PATH</envar> or <envar>HOME</envar>.
<title>Traps and traces</title>
<para>
<indexterm><primary>g_trap_free_size</primary></indexterm>
<indexterm><primary>g_trap_realloc_size</primary></indexterm>
<indexterm><primary>g_trap_malloc_size</primary></indexterm>
Some code portions contain trap variables that can be set during debugging
time if GLib has been configured with <option>--enable-debug=yes</option>.
Such traps lead to immediate code halts to examine the current program state
@ -180,6 +183,16 @@ matches the size of the corresponding memory block. This will only work with
<literal>g_mem_set_vtable (glib_mem_profiler_table)</literal> upon startup
though, because memory profiling is required to match on the memory block sizes.
</para>
<para>
Note that many modern debuggers support conditional breakpoints, which achieve
pretty much the same. E.g. in gdb, you can do
<programlisting>
break g_malloc
condition 1 n_bytes == 20
</programlisting>
to break only on g_malloc() calls where the size of the allocated memory block
is 20.
</para>
</refsect2>
</refsect1>

11
docs/reference/gobject/tut_tools.xml
View File

@ -49,6 +49,17 @@
It suports a filter-rule mechanism to let you trace only the objects you are
interested in and it can be used together with gdb.
</para>
<para>
<indexterm><primary>g_trap_object_ref</primary></indexterm>
Note that if GObject has been compiled with <option>--enable-debug=yes</option>,
it exports a trap variable
<programlisting>
static volatile GObject *g_trap_object_ref;
</programlisting>
If set to a non-NULL value, <link linkend="g-object-ref">g_object_ref</link>()
and <link linkend="g-object-unref">g_object_unref</link>() will be intercepted
when called with that value.
</para>
</chapter>
<chapter id="tools-gtkdoc">