Bug Reports

Before Reporting a Bug

Before you report a bug, please consult the Frequently Asked Questions. It contains workarounds for many of the failure conditions for which we know a workaround. This includes a large fraction of the failures people seem to encounter in practice.

After that, please search Bugzilla to see if the bug has already been reported. There are two ways to do this:

• Using the Bugzilla query page; choose Valgrind as the "product", and then type something relevant in the "words" box. If you are seeing a crash or abort, searching for part of the abort message might be effective. If you are feeling adventurous you can select the "Advanced search" tab; this gives a lot more control but isn't much better for finding existing bugs.
• Or you can view all open Valgrind bug reports at the Bugzilla all open bugs page, and use your browser's search facilities to search through them.

Note that KDE kindly lets us use their Bugzilla, which explains the URLs of those pages and all the mentions of KDE.

Anyone can search in Bugzilla, you don't need an account. Searching requires some effort, but helps avoid duplicates, and you may find that your problem has already been solved.

Reporting a Bug

If you haven't encountered your problem after those steps, please file a report using our Bugzilla report page. You need a KDE Bugzilla account to report a bug; instructions for creating one are on the page. Creating an account takes some time and effort, but it's a necessary evil when using Bugzilla.

The bug report form can be intimidating. Fortunately you don't have to fill in all the fields. Leave all fields blank except the following:

• Component: If the problem is with a specific Valgrind tool (eg. Memcheck, Cachegrind), select the tool name. If it's a Vex issue (i.e. an abort message mentions "vex"), select "vex". If it's a general problem that appears tool-independent, or you are not sure, select "general".
• Version: The version number is shown when Valgrind starts up, on the "Using valgrind-$VERSION, a dynamic binary instrumentation framework" line. A "GIT"-suffixed version will only appear if you are using code directly from the git repository.
• Severity: If Valgrind won't compile, choose "major". If you are seeing a crash, choose "crash". If your problem is minor, choose "minor" or "wishlist". Otherwise, choose "normal". Please leave the "grave" or "critical" categories to the Valgrind developers to decide.
• Platform: "unspecified" is usually fine; this field isn't very important unless it's a packaging-related problem.
• OS: This is auto-filled in, but unless you're confident it's an OS-specific problem, it's probably best to change it to "unspecified".
• Summary: This is the title of the bug report. Try to make it precise. E.g. if you get an assertion failure, don't say "assertion failure"; copy in the actual assertion failure message.
• Description: The most important field, which describes the problem. Please include the following information:
  1. The output of uname -a.
  2. The full output you get when you run your program under Valgrind with the -v flag.
  Note that a bug is much more likely to be fixed if a Valgrind developer can reproduce it. So full reproduction steps are very helpful. Small test cases are even better.

Here are some resources on how to write a good bug report, which can help your get your problem fixed quicker:

• Eric Raymond's and Rick Moen's How To Ask Questions The Smart Way
• mozilla.org's bug writing guidelines
• Simon Tatham's How to Report Bugs Effectively

After Reporting a Bug

All bug reports are read by multiple Valgrind developers. Furthermore, we try to respond to most bug reports, but we have limited time so this does not always happen. We may also ask for more information.

If a bug is confirmed (e.g. we are able to reproduce it) we will usually change its status from UNCONFIRMED to NEW or ASSIGNED. Important bugs will be given a "target" by developers indicating that they are required/desired for an upcoming. Note that we don't really use the "priority" field, so it will usually be "NOR" (normal).

Once a bug is fixed in the git repository, it is changed to RESOLVED. We do not use the VERIFIED or CLOSED statuses.

Some bugs are fixed quickly, some take a long time to get fixed, some are never fixed. Please be patient if your bug is not acted upon quickly. One great thing about Bugzilla is that, at the very least, bug reports do not get lost.

Alternatives

If you have trouble with Bugzilla, or for some reason you don't think Bugzilla is appropriate for your report (although it probably is), contact the valgrind-users mailing list. But you may just be told to file a bug in Bugzilla.