Reporting

Revision 13 as of 2008-06-03 20:31:56

Clear message

Bug Reporting

The lifecycle of a bug report begins, unsurprisingly, with the preliminary report. How a bug is initially reported can have a huge effect on how it's handled and how quickly it gets fixed. Indeed, your bug may be closed as invalid if it doesn't at least include the basics!

If you do nothing else, at least remember: BR Always include /var/log/Xorg.0.log when reporting X bugs!

Troubleshooting

If you'd like to do some investigation beyond just reporting the bug, please see the page:

["X/Troubleshooting"]

Choosing a Good Title

Your title should communicate two things: The symptom you're seeing, and whatever is unique or unusual about your system. Otherwise, your bug may not get proper attention.

Examples:

BAD:

Crashes randomly

BAD:

Crazy screen issues on boot

BAD:

Multiple problems with CD today

BAD:

Not able to login or start X after updating

GOOD:

Screen briefly corrupts during boot with -nv (NVidia 6100)

GOOD:

[fglrx] atieventsd crashed with SIGSEGV in XextAddDisplay()

GOOD:

[Hardy Alpha-3] Alt-CD (only) selected wrong driver (Matrox / BenQ FP91+)

GOOD:

[Gutsy] Periodic crashes w/ high CPU on Dell Latitude D505 (-intel 855GM)

GOOD:

[Dapper,Edgy] Wrong default refresh rates on 16:10 LCD panels

GOOD:

After update to -intel 2.0-0ubuntu3, X fails with 'Invalid mode' error

Do's and Don't's

DON'T:

Assume "they must already know about this" and skip reporting

DO:

Look for existing bug reports that exactly matches your problem, and if not file a new bug

DON'T:

Assume a "similar" bug is exactly what you're seeing

DO:

File a new bug, but mention the ID's of all bugs that sound similar. Someone can easily dupe them together later.

DON'T:

Add "me too" responses to an existing bug. Wastes everyone's time.

DO:

Add missing data (photos, logs) to add to an existing bug's "knowledge base" and to provide ample evidence that you indeed have the exact same issue. Or if you just wish to be notified, then Subscribe yourself to the bug. If in doubt, file a new bug, and reference the one you think might be a dupe, and let the experts decide.

DON'T:

Post bugs with only a brief description of the problem

DO:

Post steps to reproduce, relevant logs, config files, and data (see table below) For Xorg issues, ALWAYS ATTACH YOUR /var/log/Xorg.0.log

DON'T:

Assume "everyone" is seeing this same bug

DO:

90% of the time you are seeing something abnormal that others aren't. Consider what is unique about your system, any recent changes made, and so on.

DON'T:

Assume others will "just know" how the bug occurs

DO:

Itemize the exact steps that result in the issue. Can you reproduce it at will?

DON'T:

Fire and forget. Abandoned bugs rarely get fixed.

DO:

Follow up on your bug from time to time, even if it seems ignored. Report if the issue goes away or remains when new Ubuntu's come out.

DON'T:

Rant about the bug "driving away new users", threaten to "go back to windows or some other distro" unless the bug is fixed, or complain the bug is not getting enough attention. None of this helps get the bug fixed; it just makes people sad.

DO:

Follow the [http://www.ubuntu.com/community/conduct Ubuntu Code of Conduct] and keep discussions civil, even if you're frustrated. There are thousands of bugs and just a handful of people to work on them, and we can't fix everything overnight. If you're not getting fast enough response on a bug, then in addition to improving the report, you can try reporting it upstream, make mention of the bug directly to developers via mailing lists or irc, or even undertaking troubleshooting and analysis procedures yourself. Half the work of solving a bug is reproducing it, so if you have the bug, you're already halfway to a solution! Wink ;-) Many, many of Ubuntu's bugs are solved through the work of community members, who didn't know the underlying technology but were patient and diligent at asking questions and testing things out until they found a solution.

What to Include in Bug Reports

Problem class:

Things to Include:

General X bug

Description of problem

Paste in output of lspci -nn | grep VGA

Attach /var/log/Xorg.0.log

Wrong resolutions, refresh rates, or monitor specs

Resolution, rate, or other parameter expected

Resolutions, rates, or other parameters actually obtained

/etc/X11/xorg.conf

/var/log/Xorg.0.log

Paste in output of lspci -nn | grep VGA

output of sudo ddcprobe

output of xrandr

Wrong font dpi or size

Are you running GNOME, KDE, XFCE, or ...?

Affected (and unaffected) applications

/var/log/Xorg.0.log

output of sudo ddcprobe

Screenshot showing font differences

X crash, lockup, freeze, exit, or doesn't start/shutdown

Detailed description of problem

Get a full backtrace (["X/Backtracing"])

List any versions you tried that did not have this issue

Steps to reproduce

How complete is the X failure? BR + Does ctrl+alt+f1 take you to a console? BR + Does ctrl+alt+backspace restart X? BR + Does mouse pointer still move? BR + Does the keyboard LED come on when hitting the CAPSLOCK key? + Can you ssh into the system from another computer?

/var/log/Xorg.0.log

/var/log/Xorg.0.log.old

~/.xsession-errors

Keyboard, touchpad, and mouse issues

Description of the problem

/var/log/Xorg.0.log

output of xprop -root

output of gconftool-2 -R /desktop/gnome/peripherals

Screen display corruption

Photo of the screen

Description of the problem

Does it also occur if DRI is disabled?

/var/log/Xorg.0.log

Bad video playback

/etc/X11/xorg.conf

/var/log/Xorg.0.log

output of lspci -vvnn

What Next?

Once your X bug is reported, it will be reviewed and triaged. The triager may mark it Incomplete and ask some questions or request additional information (if you're curious, or would like to participate in triaging, see ["X/Triaging"]).

If there is no reply from you within a month or two, the bug report may be closed as out of date / invalid (otherwise the tracker fills up with inactive bugs and gets confusing). You should feel free to reopen it once you have the needed information.

Once you've submitted your replies, a second round of triaging takes place to evaluate if the bug is a Duplicate of another bug or not an issue requiring a fix. If neither of those apply, the bug will be marked Triaged, which marks it ready for the research step.

In the research step, the bug may be assigned to a developer or forwarded to an upstream bug tracker. If it is forwarded upstream, you should also subscribe to that bug report so you can answer questions or run tests for those developers.

Once a fix is found either in Ubuntu or upstream, the Ubuntu developers will take the fix and package it for Ubuntu. They may ask for people to test and verify the fix before uploading it.