1 2Traps (G_BREAKPOINT) and traces for the debugging 3================================================= 4 5Some code portions contain trap variables that can be set during 6debugging time if G_ENABLE_DEBUG has been defined upon compilation 7(use the --buildtype=debug option to configure for this, macros.txt 8covers more details). 9Such traps lead to immediate code halts to examine the current 10program state and backtrace. 11Currently, the following trap variables exist: 12 13static volatile gulong g_trap_free_size; 14static volatile gulong g_trap_realloc_size; 15static 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. 22static volatile GObject *g_trap_object_ref; 23 If set to a valid object pointer, ref/unref will be intercepted 24 with G_BREAKPOINT (); 25static volatile gpointer *g_trap_instance_signals; 26static 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 (); 31 32Environment variables for debugging 33=================================== 34When G_ENABLE_DEBUG was defined upon compilation, the GObject library 35supports an environment variable GOBJECT_DEBUG that can be set to a 36combination of the flags passed in to g_type_init() (currently 37"objects" and "signals") to trigger debugging messages about 38object bookkeeping and signal emissions during runtime.