Submitting a Bug Report

If you would like to submit a bug report against GLIBC please read the GNU Guidelines for filing a GLIBC bug.

Before you file, take a look at the GLIBC duplicate bugs page to see if you're filing something that's already been identified. Also do a query in bugzilla before you file.

  1. Do not report build errors in bugzilla! Take it to #glibc on freenode or to the libc-help mailing list. If you've identified an actual problem with a Makefile you can bring that to libc-alpha directly.
  2. No man pages are part of glibc, DO NOT REPORT MAN PAGE BUGS HERE! There is a separate GLIBC man page project. Todo: identify

The Sourceware Bugzilla hosts GLIBC bugs under the glibc product.

Guidelines for Bugzilla Severity and Priority

Bugzilla severity and priority guidelines:

Every once in a while Ulrich will make a statement about what severity and priority is allowed for a particular type of bugs. We need to find and document those guidelines.

GLIBC Bugzilla Bug Triage

We're looking for volunteers to help with the GLIBC Bugzilla bug triage initiative who have the following duties:

  1. Deal with new bug reports in a timely manner.
  2. Identify duplicate bugs reports. Close duplicate reports as 'dupe'. The will show up on the GLIBC duplicate bugs page.

  3. Verify bug validity, which involves the following:
    • Verify the validity of the test-case (identify user error).
    • Verify the behavior against the existing documentation (info page and man page).
    • Verify the bug premise against applicable standards (i.e. C99, POSIX, ieee754, ieee754r, ieee854).
    • Ask for clarification of standards and documentation from developers.
  4. Narrow the breadth of the bug's scope if applicable.

  5. Implement a minimal test-case from a user submitted test-case or create one if a test-case is lacking.
  6. Create a test-case that can be injected into the GLIBC test-skeleton.c framework.
  7. Pester developers via posting to libc-alpha.
  8. Once fixes are delivered verify that problem is fixed.
  9. Prepared fixes to man pages or info pages as necessary.

Further reading of Roland McGrath's comments regarding GLIBC bug triage can be found here.