| 7 | | In general, if you have a bug to submit follow the instructions: |
| | 7 | When 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]. |
| | 8 | |
| | 9 | Please include in your bug report all of the following items: |
| | 10 | |
| | 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 |
| | 17 | |
| | 18 | Only 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. |
| | 19 | |
| | 20 | If 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. |
| | 21 | |
| | 22 | == What we do not want == |
| | 23 | |
| | 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. |
| | 35 | |
| | 36 | Developing 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. |
| | 37 | |
| | 38 | == Not RTEMS Bugs == |
| | 39 | |
| | 40 | RTEMS users sometimes encounter that may be considered bugs in RTEMS but are not. |
| | 41 | |
| | 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 == |
| | 47 | |
| | 48 | To submit a bug report please follow the instructions: |
![[RTEMS Logo]](/images/logo.png){kind=logo}
