Changes between Version 10 and Version 11 of Developer/Bug_Reporting

Mar 22, 2015, 3:59:24 AM (4 years ago)
Chris Johns

Merged another page in.


  • Developer/Bug_Reporting

    v10 v11  
    55Our preferred way of receiving bug reports is via the [ RTEMS Trac] ticket system. If you have patches not specifically related to bugs or existing tickets, we prefer to use the [wiki:TBR/Website/RTEMSMailingLists Developer's Mailing List].
    7 In general, if you have a bug to submit follow the instructions:
     7When you have checked that your report meets the following criteria, please submit it according to the generic instructions in [wiki:Developer/Bug_Reporting#Bugreportinginstructions Reporting a Bug].
     9Please include in your bug report all of the following items:
     11 *  The exact version of RTEMS
     12 *  The system type (CPU family, model, and BSP)
     13 *  The compiler toolchain version used
     14 *  The options given when RTEMS was configured/built
     15 *  A description of the expected behaviour
     16 *  A description of actual undesired behaviour
     18Only when your bug report requires multiple source files to be reproduced should you use an archive otherwise an individual source file or a diff should be uploaded that contains the minimal set of source code for reproducing the bug. In any case, make sure the above are included in the body of your bug report as plain text, even if needlessly duplicated as part of an archive. Please try and repeat on the current git master.
     20If you fail to supply enough information for a bug report to be reproduced, someone will probably ask you to post additional information. In this case, please post the additional information and not just to the person who requested it, unless explicitly told so.
     22== What we do not want ==
     24 *  A source file that `#includes` header files that are left out of the bug report (see above).
     25 *  That source file and a collection of header files.
     26 *  An attached archive (tar, zip, shar, whatever) containing any of the above.
     27 *  A code snippet that won't cause RTEMS to produce the exact output mentioned in the bug report.
     28 *  The location (URL) of the package that failed to build.
     29 *  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.
     30 *  Assembly files (*.s) produced by the compiler, or any binary files, such as object files, executables, core files, or precompiled header files.
     31 *  Duplicate bug reports, or reports of bugs already fixed in the development tree.
     32 *  Bugs in the assembler, the linker or the C library. These are separate projects, with separate mailing lists and different bug reporting procedures. The RTEMS Project is happy to work with you and those projects to resolve the problem but we must work with those projects.
     33 *  Bugs in releases or snapshots of RTEMS not issued by the RTEMS Project. Report them to whoever provided you with the release.
     34 *  Questions about the correctness or the expected behaviour of programming language constructs or calls to library routines that are not part of RTEMS.
     36Developing and debugging real-time embedded systems can be difficult. Exercise caution in reporting an error that occurs only some of the times a certain program is executed, such that retrying a sufficient number of times results in a successful compilation; this is often a symptom of a hardware problem or application issue, not of a RTEMS bug (sorry). We do recognise that sometimes a timing bug will exist in RTEMS but want you to exercise due diligence before pointing fingers.
     38== Not RTEMS Bugs ==
     40RTEMS users sometimes encounter that may be considered bugs in RTEMS but are not.
     42 *  The POSIX standard does NOT specify the default set of thread attributes. Thus when passing a NULL for attributes to pthread_create, the application is not guaranteed any particular thread behavior.
     43 *  The defaults for all RTEMS Configuration Table parameters are intentionally small. Thus it is common for RTEMS tasking and file related calls to return errors indicating out of resources until the configuration parameters are properly tuned for the application. For example, there are only 3 file descriptors available by default: stdin, stdout, and stderr. Any attempt to open a socket or file will fail unless more file descriptors are configured.
     44 *  When first developing a BSP, many users encounter an unexpected interrupt or exception immediately upon completion of RTEMS initialization. This occurs because interrupts are disabled during RTEMS initialization and are automatically initialized as part of switching to the first task. The interrupted user code will be in either _CPU_Context_switch or _Thread_Handler. This indicates that an interrupt source has not been properly initialized or masked.
     45 *  Some users encounter a random reset during BSP initialization. This usually indicates that the board has a watchdog timer that is not being properly serviced during the BSP initialization.
     46== Reporting a Bug ==
     48To submit a bug report please follow the instructions:
    9501. Sign in to the RTEMS Trac website using the [ Trac Login].
    2061The [wiki:TracWorkflow Trac Ticket Workflow] details the workflow for RTEMS Tickets.
    22 = Managing Bugs =
     63Before you report a bug, please check the list of [wiki:#Non-Bugs #Non-Bugs] and a current development snapshot. If you want to report a bug with older versions of RTEMS, we strongly recommend upgrading to the current release first.
     65== Managing Bugs ==
    2467This section contains information mostly intended for RTEMS contributors.  But if you submit a bug report, it is very important for you to submit a reproducible test case.  These submitted test cases end up being added to the test suite to prevent future regressions.