Bugs
	Main page	Bugs	Manual	Resources

Reporting Bugs

The main purpose of a bug report is to enable us to fix the bug. The most important prerequisite for this is that the report must be complete and self-contained, which we explain in detail below.

Before you report a bug, please check the list of well-known bugs and, if possible in any way, try a current CVS development snapshot.

General Information about filing bugs

What bugs should be reported?

Most users do not compile the GNU C Library from the sources released by the GNU developers. Most people are using glibc binaries supplied with a complete operating system distribution (for a comprehensive list of distributions see Linux Weekly News Distributions page). Distributions include their own modifications to glibc in the binaries and sources you get with the operating system. If the glibc you are using comes from a complete operating system distribution, you should report bugs to that distribution project first. Your distribution's own documentation and web pages should refer you to their bug-reporting system. Your distribution's maintainers will determine whether the problem is specific to their modifications or other details of that particular system. If the problem does exist in the standard GNU C Library code, they will report it to the GNU maintainers or direct you how to do so.

So you still want to file a bug?

If you have determined that your bug should be directed directly to the GNU developers and not your distribution maintainers, your next step should be to check the latest CVS sources.  Information on the glibc CVS repository can be found at the glibc status page.

As a rule, bug reports should generally be filed against the current CVS versions at the time you file the bug.  glibc development can move quickly at times and you will often find your specific bug has already been fixed.

Where to file a bug

glibc runs a bugzilla database where all bugs should be recorded. 

Bug reporting instructions

Step 1. Check your bug against CVS glibc

You might save yourself significant effort by simply checking the problem still exists with current development snapshots (see the resources page for more information). Building glibc is a tricky business, and glibc maintainers will generally not offer generous support for people having problems building the library.

Step 2. Search for existing bugs

Your bug may already have been reported.  Firstly, use a general web search engine such as Google to investigate your problem.  Search engines should index many different mailing lists where others may have explored the same problem.

Secondly, try your search via the search functionality provided at the libc-alpha, libc-hacker and libc-ports information pages (see resources for more relevant mailing lists).  These are the main lists where the GNU developers discuss glibc issues.

Finally, use the query existing bug reports and the most frequently reported bugs forms to attempt to identify your bug in Bugzilla.  If you find your bug some relevant actions (in increasing order of usefulness) might be

• Add yourself to the CC list for the bug to keep informed about developments.
  
• Confirmation of the bug in a different environment or architecture.
  
• More information on how to trigger the bug.
  
• A self contained test case to replicate the bug, if one does not exist.
• A patch to correct the bug.

Step 3. File a new bug

If your bug does not appear to exist, you may file a new bug with the new bug form.  Bugzilla contains a general bug writing guide explaining the interface.  Please take into account the following guidelines:

Duplicate Bugs

Even if you think a bug is new, expert glibc bug hunters may recognise it as a symptom of an existing problem and mark it as duplicate.

Support Categories

Support is broadly divided up into components relating to divisions in the libc source code.  Please read the component descriptions and file your bug appropriately.

What to put in a new report

• The glibc version you are using; either from a official release or the date and time you checked out CVS.
• The host/build/target triplets
• • If you are cross compiling, you should already know these.
  • If you otherwise don't know use the output of scripts/config.guess
• The options given to the ./configure command
• The kernel you are running (obtain the output of uname -a)
• The version of gcc and toolchain you are using to build glibc(obtain the output of gcc -v and ld -v)
• A description of the problem and some way to replicate the problem.  The only way to guarantee anyone will look at your bug report is to provide a self contained test case that illustrates the problem; it is far too time consuming for developers to track down problems in other peoples code. If the developers can not replicate the problem, there is little hope of getting it fixed.
• Any analysis of the problem you have performed.
• If your bug relates to incorrect behaviour of standardised interfaces, a link to the appropriate section of the standard.

What not to put in a new report

• Any binary files.
• An attached archive (tar, zip, shar, whatever) containing any of the above.
• E-mail messages that complement previous, incomplete bug reports. Post a new, self-contained, full bug report instead, if possible as a follow-up to the original bug report
• Duplicate bug reports, or reports of bugs already fixed in the development tree, especially those that have already been reported as fixed last week.
• Bugs in gcc, the linker/assembler or your application. These are all separate projects, with separate mailing lists and different bug reporting procedures
• Bugs in releases or snapshots of glibc not issued by the GNU Project. Report them to whoever provided you with the release (usually your distribution).
• Questions about the correctness or the expected behaviour of standardised system calls.  These might be more appropriately asked in other forums.

Support Forums

There are a number of mailing lists relevant to glibc development. Please check the resources page for a complete list.