FilingBugs

Revision 10 as of 2010-12-01 18:48:38

Clear message

If you find an issue with Unity, here are some guidelines for filing bugs and providing details to the development team

Different bugs

First, we're mostly interested in crashers, features that are not working as expected or integration issues.

If you have an issue with the design or the usability of Unity, it's better to contact the design team first before filing a bug against Unity. Or better, tag your bug report as opinion or whishlist, so we'll know who should deal with it.

Where to file bugs?

You should file bugs against Unity in Launchpad.

Even if the issue is actually in Compiz, it's still worth filing the bug against Unity, and we'll triage things to point to compiz as well. We're working very closely with the Compiz project.

How to file bugs with apport (easy way)?

When a crasher occurs on your system you should get an apport dialog inviting you to report the issue.

If the dialog doesn't appear for some reason, you can check that a crasher trace has been collected by looking into the /var/crash directory. You should see a filename containing 'compiz'.

ls -altr /var/crash to list them in chronological order.

To manually trigger a bug report:

  • stay in your current X session
  • add a window manager from a TTY if needed, ie CTRL-ALT-F1, login, DISPLAY=:0 metacity --replace

  • then do: apport-bug -c /var/crash/<latest compiz crash file> and follow the procedure in the web page that should open shortly after you invoke this command. Note that focus issues may prevent the page to appear on the top, but look for a new browser window opened in your workspace.

How to file bugs without apport (hard way)?

If for some reason apport was not enabled on your system, or if you have a reproducible issue we ask you to investigate, here is how you can generate a stack trace and inspect internal variables.

Getting a backtrace

Ensure that you have the debugging symbols for the compiz, nux and unity packages. If you want compiz to spit out a backtrace when it crashes, you can grab the crashhandler plugin from git and enable that in ccsm.

Otherwise, from tty1 (Ctrl + Alt + F1)

$ export COMPIZ_CONFIG_PROFILE=ubuntu
$ DISPLAY=:0 gdb compiz
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/mutter...(no debugging symbols found)...done.
(gdb) set args --replace
(gdb) set logging file 'compiz.log'
(gdb) run

[ and when compiz crashes, do...]

(gdb) bt full

[ then CTRL-D or re-run compiz to continue working ]

(gdb) run

You can also get a valgrind trace by running valgrind compiz --replace & in a terminal. This is a little bit slower to get because it runs compiz under emulation, but it does produce some output which isn't possible to get from gdb.

Old instructions for the Mutter version on Maverick only (backtrace, the hard way)

$ DISPLAY=:0 gdb mutter

instead of compiz