Submitting Problem Reports

If you want to submit bug or problem report, fill in the submit form. After you send the submit button, your message will be queued to GNATS. GNATS usually process the queue each several minutes. After your message is processed, you will be notified by e-mail (so it is important to fill in right e-mail address). If you will not have received the notification within a day after successful submission, you should probably contact the GNATS administrator on this site. You can find his address in the foot of the index page.

The form contains the fields described in the next section. See also the section with useful hints about submitting problem reports.

Submit form

Depending on local gnats2w configuration, not all of the described fields must be present in your form.

Category

The name of the product, component or concept where the problem lies. Just select one. [L] describes the categories.

Release

Release or version number of the product, component or concept. Examples: 0.6, 19990225.

Confidential

If you check in this field, the problem will be considered as confidential. What it means exactly is depending on local gnats2w configuration. Usually confidential problems reports can be viewed and edited only by people with special access rights to the bug tracking system.

Subject

One-line summary of the problem. The bug tracking system copies this information to the subjects of mails sent by the system and this identification is also used in various places of the WWW interface. Example: Incorrect date of closing.

Class

The class of a problem can usually be one of the following (the list may vary depending on a particular bug database):

sw-bug
A general product problem.
doc-bug
A problem with the documentation.
change-request
A request for a change in behavior, etc.
support
A support problem or question.

Select one.

Severity

The severity of the problem. Possible values include:

critical
The product, component or concept is completely non-operational or some essential functionality is missing. No workaround is known.
serious
The product, component or concept is not working properly or significant functionality is missing. Problems that would otherwise be considered critical are rated serious when a workaround is known.
non-critical
The product, component or concept is working in general, but lacks features, has irritating behavior, does something wrong, or does not match its documentation.

Select one.

Priority

How soon the originator requires a solution. Possible values include:

high
A solution is needed as soon as possible.
medium
The problem should be solved in the next release.
low
The problem should be solved in a future release.

Select one.

Submitter

Your name. It is not necessary to fill in this field if you do not want.

Email

If you want to ever receive any answer or notification about your problem, it is a good idea to fill in your correct e-mail address here.

Description

Precise description of the problem. Proper information in this field is crucial for diagnosing the problem, so try to fill in it carefully, please.

See also some useful hints about reporting problems.

How To Repeat

Example code, input, or activities to reproduce the problem. The support organization uses example code both to reproduce the problem and to test whether the problem is fixed. Include all preconditions, inputs, outputs, conditions after the problem, and symptoms. Any additional important information should be included. Include all the details that would be necessary for someone else to recreate the problem reported, however obvious. Sometimes seemingly arbitrary or obvious information can point the way toward a solution.

See also some useful hints about reporting problems.

How To Fix

A description of a solution to the problem, or a patch which solves the problem. (This field is most often filled in at the Support Site; we provide it to the submitter in case she has solved the problem.)

Environment

Description of the environment where the problem occurred: machine architecture, operating system, host and target types, libraries, pathnames, etc.

Helpful hints

There is no orthodox standard for submitting effective bug reports, though you might do well to consult the section on submitting bugs for GNU gcc in the GCC manual by Richard Stallman. This section contains instructions on what kinds of information to include and what kinds of mistakes to avoid.

In general, common sense (assuming such an animal exists) dictates the kind of information that would be most helpful in tracking down and resolving problems in software.