1 2 Traps (G_BREAKPOINT) and traces for the debuging 3 ================================================ 4 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 8 covers more details). 9 Such traps lead to immediate code halts to examine the current 10 program state and backtrace. 11 Currently, the following trap variables exist: 12 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 24 with G_BREAKPOINT (); 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 (); 31 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. 39 40 41 2000/02/04 Tim Janik 42
