Debugging

GLib logging

GLib provides a family of logging macros. Prefer these over printf — they respect log level filters and can be redirected:

Control which levels are printed:

G_MESSAGES_DEBUG=all ./my-mate-app          # all levels including debug
G_MESSAGES_DEBUG=MyApp ./my-mate-app        # debug for a specific domain only

Set the log domain at the top of each source file:

#define G_LOG_DOMAIN "MyApp"

Turn warnings and criticals into hard crashes during development to catch them early:

G_DEBUG=fatal-warnings ./my-mate-app

GDB

Build with debug symbols first:

./autogen.sh --prefix=/usr CFLAGS="-g -O0"
make

Then run under GDB:

gdb ./src/my-mate-app
(gdb) run
# After a crash:
(gdb) backtrace
(gdb) frame 3
(gdb) print variable_name

GLib/GObject helpers for GDB

Load the GLib pretty-printers to display GLib types readably:

# In GDB or ~/.gdbinit:
python
import sys
sys.path.insert(0, '/usr/share/glib-2.0/gdb')
import glib_gobject_helper
end

After loading, print on a GObject * shows its type name and ref count.

Useful GDB commands for GObject code:

(gdb) call g_type_name(G_TYPE_FROM_INSTANCE(obj))
(gdb) call g_object_get_data(obj, "key")
(gdb) watch obj->ref_count

Catching GLib criticals

(gdb) break g_log_default_handler
(gdb) run

This stops execution at every g_warning / g_critical, letting you inspect the call stack.

GTK Inspector

GTK Inspector is an interactive debugger built into GTK 3. Launch it with:

GTK_DEBUG=interactive ./my-mate-app

Or press Ctrl+Shift+I inside a running app. Capabilities:

• Widget tree — browse and select any live widget to see its properties and CSS
• CSS editor — write and preview CSS changes immediately
• Signal recorder — log every signal emission
• Object statistics — count live GObject instances by type (useful for leak hunting)

Valgrind — memory leak detection

valgrind --leak-check=full \
         --show-leak-kinds=definite,indirect \
         --num-callers=30 \
         ./src/my-mate-app

Suppress known GLib/GTK false positives:

valgrind --suppressions=/usr/share/glib-2.0/valgrind/glib.supp \
         --leak-check=full ./src/my-mate-app

Key output to look for:

• definitely lost — real leaks you own
• indirectly lost — leaked through a pointer in a directly-lost block
• still reachable — held in globals at exit (often intentional in GTK apps)

AddressSanitizer (ASan)

Faster than Valgrind for catching heap corruption, use-after-free, and buffer overflows:

./autogen.sh --prefix=/usr CFLAGS="-g -O1 -fsanitize=address" \
             LDFLAGS="-fsanitize=address"
make
./src/my-mate-app

ASan reports are printed to stderr with a full stack trace.

Core dumps

ulimit -c unlimited
./src/my-mate-app          # let it crash
gdb ./src/my-mate-app core
(gdb) backtrace

On systems using systemd-coredump:

coredumpctl list
coredumpctl gdb my-mate-app

Environment variable reference