Running GLib Applications

Running GLib Applications — How to run and debug your GLib application

Running and debugging GLib Applications

Environment variables

GLib inspects a few of environment variables in addition to standard variables like LANG, PATH or HOME.

G_BROKEN_FILENAMES. If this environment variable is set, GLib assumes that filenames are in the locale encoding rather than in UTF-8.

G_MESSAGES_PREFIXED. A list of log levels for which messages should be prefixed by the program name and PID of the application. The default is to prefix everything except G_LOG_LEVEL_MESSAGE and G_LOG_LEVEL_INFO.

G_DEBUG. If GLib has been configured with --enable-debug=yes, this variable can be set to a list of debug options, which cause GLib to print out different types of debugging information.

fatal_warnings

Causes GLib to abort the program at the first call to g_warning(). This option is special in that it doesn't require GLib to be configured with debugging support.

G_RANDOM_VERSION. If this environment variable is set to '2.0', the outdated pseudo-random number seeding and generation algorithms from GLib-2.0 are used instead of the new better ones. Use the GLib-2.0 algorithms only if you have sequences of numbers generated with Glib-2.0 that you need to reproduce exactly.

Traps and traces

Some code portions contain trap variables that can be set during debugging time if GLib has been configured with --enable-debug=yes. Such traps lead to immediate code halts to examine the current program state and backtrace.

Currently, the following trap variables exist:

static volatile gulong g_trap_free_size;
static volatile gulong g_trap_realloc_size;
static volatile gulong g_trap_malloc_size;

If set to a size > 0, g_free(), g_realloc() and g_malloc() will be intercepted if the size matches the size of the corresponding memory block. This will only work with g_mem_set_vtable (glib_mem_profiler_table) upon startup though, because memory profiling is required to match on the memory block sizes.