Drop memory-related trap variables
[platform/upstream/glib.git] / docs / reference / glib / running.xml
index 67699d9..40b0a37 100644 (file)
@@ -274,48 +274,6 @@ returned by functions like <function>strftime()</function>.
 
 </refsect2>
 
-<refsect2>
-<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
-and backtrace.
-</para>
-
-<para>
-Currently, the following trap variables exist:
-<programlisting>
-static volatile gulong g_trap_free_size;
-static volatile gulong g_trap_realloc_size;
-static volatile gulong g_trap_malloc_size;
-</programlisting>
-If set to a size > 0, <link linkend="g-free">g_free</link>(),
-<link linkend="g-realloc">g_realloc</link>() and
-<link linkend="g-malloc">g_malloc</link>() will be intercepted if the size
-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>
-
-<refsect2>
-<title>Gdb debugging macros</title>
-
 <para>
 glib ships with a set of python macros for the gdb debugger. These includes pretty
 printers for lists, hashtables and gobject types. It also has a backtrace filter