User Tools

  • Logged in as: anonymous (anonymous)
  • Logout

Site Tools


mantis:frama-c:bug_reporting_guidelines

Using the Bug Tracking System

  • You must have an account to report an issue on the Bug Tracking System (BTS). If you are creating your account for your first bug report, consider this trade-off carefully: we will never use your e-mail address to contact you for something other than the bug you reported. But if you provide an invalid e-mail address, your bug may linger for months because the assignee is waiting for more feedback and you didn't receive the notice.
  • Use English to report an issue on the BTS. Using French is also acceptable to report a private issue.
  • Whenever possible, include HOW TO REPRODUCE the issue. Provide everything necessary for a smart, but not mind-reading, human to reproduce the bug: input files, command line used, sequence of actions. If your analysis project depends on system headers, please use one of the two options from this message.
  • If possible, attach the automatically-generated journal (by default called frama_c_journal.ml). Journals are enabled automatically when you use the GUI, or when using option -journal-enable. Including a journal or a backtrace when available does not exempt you from providing the input files: a backtrace or a journal alone do not contain enough information to reproduce the behavior.
  • Include the OBTAINED BEHAVIOR in enough detail that someone else (smart, but not mind-reading) can decide if they have reproduced your bug.
  • Include the CATEGORY, that is which part of Frama-C is concerned by your bug report or feature request. Note that issues related to Why, including issues with Why's Graphical User Interface, must be classified in the category “Plug-in > Jessie” (and not in the category “Graphical User Interface” which is only relevant for issues specific to Frama-c's GUI).
  • If the bug report is not for a crash, include the EXPECTED BEHAVIOR that you would have liked to see.
  • The status of an issue may be one of the following:
    • new (lightred): the issue has not been yet considered by any Frama-C developer.
    • assigned (mauve): the issue has been assigned to a Frama-C developer (automatically or manually by another Frama-C developer). However the assignee has not yet considered this issue.
    • acknowledged (orange): the issue has been considered by the assignee (or by any Frama-C developer if there is no assignee) but not yet deeply investigated.
    • confirmed (yellow): the issue has been confirmed by the assignee (or by any Frama-C developer if there is no assignee). It is really a bug or a wished feature.
    • resolved (lightgreen): the issue has been fixed by the assignee. The Frama-C development version contains the patch which will be part of a future release.
    • closed (lightgray): the issue is no more relevant. Either it is not really a bug or a wished feature, or it is fixed in a public release available from the download page of Frama-C.
    • feedback (magenta): the issue was previously considered resolved or closed but has been reopened.
  • Remark: the feedback status is also used when the assignee requires additional information from the reporter.
mantis/frama-c/bug_reporting_guidelines.txt · Last modified: 2014/05/29 10:59 by yakobowski