2 Traps (G_BREAKPOINT) and traces for the debuging
3 ================================================
5 Some code portions contain trap variables that can be set during
6 debugging time if G_ENABLE_DEBUG has been defined upon compilation
7 (use the --enable-debug=yes option to configure for this, macros.txt
9 Such traps lead to immediate code halts to examine the current
10 program state and backtrace.
11 Currently, the following trap variables exist:
13 static volatile gulong g_trap_free_size;
14 static volatile gulong g_trap_realloc_size;
15 static volatile gulong g_trap_malloc_size;
16 If set to a size > 0, g_free(), g_realloc() and g_malloc()
17 respectively, will be intercepted if the size matches the
18 size of the corresponding memory block to free/reallocate/allocate.
19 This will only work with g_mem_set_vtable (glib_mem_profiler_table)
20 upon startup though, because memory profiling is required to match
21 on the memory block sizes.
22 static volatile GObject *g_trap_object_ref;
23 If set to a valid object pointer, ref/unref will be intercepted
25 static volatile gpointer *g_trap_instance_signals;
26 static volatile gpointer *g_trace_instance_signals;
27 If set to a valid instance pointer, debugging messages
28 will be spewed about emissions of signals on this instance.
29 For g_trap_instance_signals matches, the emissions will
30 also be intercepted with G_BREAKPOINT ();
32 Environment variables for debugging
33 ===================================
34 When G_ENABLE_DEBUG was defined upon compilation, the GObject library
35 supports an environment variable GOBJECT_DEBUG that can be set to a
36 combination of the flags passed in to g_type_init() (currently
37 "objects" and "signals") to trigger debugging messages about
38 object bookkeeping and signal emissions during runtime.