Skip to content

HowTo: Debugging

Jump to bottom
Mario Cianciolo edited this page Oct 27, 2016 · 6 revisions

This page explains how to debug Multiload-ng.

Introduction

First of all, it's worth saying that the way of debugging a panel plugin depends strictly on the panel. This document will try to guide you into debugging a problem in a panel or in the plugin.

Prerequisites

Follow these steps for a successful debug session.

  1. enable debug CFLAGS by running ./configure with option --enable-debug (see README for build instructions)
  2. enable verbose messages running from terminal: export G_MESSAGES_DEBUG=multiload-ng

Debugging into a panel

If the problem you're trying to fix is in the "glue" code between the plugin and the panel, it could be useful to debug the plugin when it's into the panel. This process is not the same in every panel:

  • in panels where every plugin is a separate process, you can attach GDB to a running plugin
  • in single-process panels, you can try to attach GDB to the panel itself.

If your panel has debugging options (other then build flags), enable these. --sync is a common option.

XFCE users: take a look at this link that explains usage of PANEL_DEBUG environment variable.
MATE users: take a look at this link that explains how to debug MATE DBUS applets (like Multiload-ng) using gdb and mate-panel-test-applets.

Debugging the plugin alone

If the problem you're trying to fix is in the plugin code, you can run the plugin without panels by building standalone target of Multiload-ng, that is the plugin wrapped in a simple GtkWindow.

I strongly suggest using standalone target for debug. It has the following advantages:

  • it's so much easier to debug, not being embedded in any panel
  • helps isolating problems related to plugin and problems related to panels
  • does not rely on panel being debuggable

To attach GDB to standalone Multiload-ng, just build it (see README for build instructions) and then, in source directory, type:
`gdb standalone/multiload-ng'

Start debugging

Once you have a running GDB session, start the program by typing:
run

Breakpoints

You can set breakpoints to inspect behavior and variables in every point of the program. You can also change variable values at runtime. Read any GDB tutorial for beginners to learn how to use GDB and breakpoints.

Backtrace

The most common use of GDB is probably obtaining a backtrace. When a program crashes under GDB control (often by segmentation fault), GDB is capable to produce a backtrace, that is the call sequence that brought to the crash.

Every line of the backtrace contains a function (alongside with filename and line), next line contains function that called it. Backtraces can be obtained at every breakpoint, not just on crashes.

To get backtrace (developer may ask it if you are sending a crash report) just type this in a running GDB session:
backtrace

Clone this wiki locally