GNOME/Submitting Bugs

From openSUSE

To report GNOME bugs, two things are needed:

• Install the -debuginfo packages, that contain symbol information on all binaries, very helpful to submit useful information about crashes.
• Install bug-buddy. This application will be started anytime a GNOME application crashes, and collect all information it can about the crashed application. (FIXME: we need to make bug-buddy report bugs to https://bugzilla.novell.com/).
• Check the sections below to see if the software you are using has extra steps to provide debugging information.

To check for upstream bugs, go to http://bugzilla.gnome.org.

Getting stack traces by hand

If bug-buddy does not appear when your program crashes, do this (what you type is in boldface):

$ gdb gedit             # or the name of the process that crashed
(gdb) r
... lots of stuff ...         # trigger the crash
(gdb) thread apply all bt
... ATTACH THIS PART TO A BUG REPORT ...
(gdb)

If the process you are tracing starts on login, then use the following procedure:

$ pidof nautilus        # or the name of the process that crashed 
12345
$ gdb
(gdb) attach 12345
... lots of stuff ...
(gdb) thread apply all bt
... ATTACH THIS PART TO A BUG REPORT ...
(gdb)

Sometimes it's useful to break the execution when a warning is shown, in which case it is very useful to do the following:

(gdb) break g_logv

This will break in g_logv, the GLib call that displays all warnings. When gdb stops execution in g_logv, you can get a back trace (thread apply all bt) to determine where the warning comes from.

Getting additional information

There are some useful ways to get extra information for the process being debugged:

This will get system calls performed by the application which pid is <pid>:

$ strace -f -ttt -o /tmp/strace-log -s 4096 -p <pid>

It will save a list of all system calls, in order, in the /tmp/strace-log file.

When applications leak memory, valgrind is very useful:

$ valgrind --tool=memcheck --num-callers=128 <application>

valgrind runs the application and detects all memory operations, as well as other data access problems, so be sure to capture its output and attach that to the bug.

When dealing with DBus-based applications, dbus-monitor is very helpful.

Additional debugging information

Some applications provide a logging mechanism to retrieve further information about the running of the application itself.

Beagle

http://beagle-project.org/Troubleshooting

GNOME Power Manager

GNOME Power Manager provides a way to get detailed step-by-step information of what the program does. To do this, some arguments need to be passed to gnome-power-manager, so to better get detailed information, it is recommended to:

$ killall -9 gnome-power-manager
$ gnome-power-manager --no-daemon --verbose > /tmp/gpm.log 2>&1

These 2 commands will kill and restart gnome-power-manager with the appropriate arguments (--no-daemon --verbose) and will copy all output from g-p-m to the /tmp/gpm.log file, which is the one that should be attached to the bug corresponding to the problem being debugged.

When the g-p-m logs don't show anything useful, it might be due to a problem in the underlying architecture (HAL and pm-utils), so to get more information:

• pm-utils logfile is /var/log/pm-suspend.log
• More information about ACPI debugging at http://en.opensuse.org/ACPI_Suspend_debugging

GNOME Screensaver

The best way to debug gnome-screensaver problems is as follows:

$ killall -9 gnome-screensaver
$ gnome-screensaver --no-daemon --debug > /tmp/gs.log 2>&1

All the logging information would be in the gile /tmp/gs.log which should be attached to the bug you file.

Nautilus

Nautilus has a debug logging infrastructure. If Nautilus crashes, it will write a ~/nautilus-debug-log.txt file which you can attach to a bug report. This file contains a log of your last actions, and additional information which may be useful to debug the problem.

Additionally, you can send the Nautilus process a SIGUSR1 signal at any time to cause it to write the debug log. This is useful when you need to debug a problem that does not make Nautilus crash, but you would still like to get some logging information out of it. You can do this by doing

 killall -USR1 nautilus

A developer may ask you to set up a ~/nautilus-debug-log.conf file with this format:

 [debug log]
 max lines = 1000
 enable domains = <list of log domains separated by ";">

Make sure you restart Nautilus after creating that file! You can do this simply by logging out and logging back in.

The available log domains are these:

• async - to debug asynchronous notifications.
• GLog - only used to get g_debug() messages included in the log; they are excluded by default. Other GLog output is included as it usually consists of important messages.
• drives-volumes - to debug discovery of drives and volumes, or removable media.
• desktop-links - to debug creation of desktop links (desktop icons).

A sample ~/nautilus-debug-log.conf may contain this:

 [debug log]
 max lines = 5000
 enable domains = drives-volumes;async

Sabayon

Sabayon will write a debug log to /root/sabayon-debug-log-xxxxxxx.txt (or to whatever root's home directory is) if it terminates abnormally. It will also write that file if it finds an abnormal situation from which it can recover (for example, a bug while saving a part of the user profile).

For debugging purposes, the admin can enable more detailed logging. To do this, create a file called sabayon-debug-log.conf in root's home directory. Put the following text in the ~root/sabayon-debug-log.conf file:

 [debug log]
 max lines = 1000
 enable domains = <list of domain names separated by ";">

For example, to enable logs from the storage and files-source modules, you would use a line like this:

 enable domains = storage;files-source

These are the available domain names. Note that by default they are not logged unless you list them in the sabayon-debug-log.conf file:

• user-profile - Main module to handle user profiles.
• storage - Module to save user profiles to a .zip bundle.
• panel-delegate - Understands changes which affect the GNOME Panel and its applets.
• gconf-source - Monitoring changes in GConf data and logging/saving/restoring them.
• files-source - Monitoring of changes in the temporary home directory and logging/saving/restoring them.
• mozilla-source - Understands changes in the configuration of Mozilla Firefox.
• proto-session - Low-level setup of the nested session (X authority, X displays, etc.).
• usermod - Low-level utilities to create a temporary home directory.
• dir-monitor - Low-level monitoring of the file system.
• user-db - Maintains an association between users and profiles.
• cache - Retrieves and caches the contents of remote URIs.
• admin-tool - Toplevel operations in the sabayon program (not normally needed).
• sabayon-apply - Toplevel operations in the sabayon-apply helper program (not normally needed).
• sabayon-session - Toplevel operations in the sabayon-session helper program (not normally needed).
• deprecated - Turns on warnings about using deprecated Python or pygtk features (not normally needed).