Sebastian Huber commented on a discussion on c-user/fatal-error/background.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/30#note_109950 > + > +In certain error conditions, it may be unreliable to carry out the following > +steps of the termination procedure since the read-write data may be corrupt. > +One of the fatal extensions of the initial extension set should reset the > +system to stop the system termination procedure. > > After invoking the fatal extensions of the initial extension sets, the > fatal extensions of the :term:`dynamic extension sets` are invoked. For > this > procedure valid read-write data is required. > > -Once all fatal extensions are executed, the system state is set to > -:c:macro:`SYSTEM_STATE_TERMINATED`. > - > -The final step is to call the CPU port or BSP specific function > -:c:func:`_CPU_Fatal_halt()`. > +Once fatal extensions were invoked, maskable interrupts are disabled and the Actually, right now in the code, the fatal extensions are invoked without explicitly disabling maskable interrupts. After a second look, I think this should be changed as well to: ```c void _Terminate( Internal_errors_Source the_source, Internal_errors_t the_error ) { ISR_Level level; _ISR_Local_disable( level ); (void) level; _User_extensions_Fatal( the_source, the_error ); /* * Everything after invoking the fatal extensions is essentially dead code. * At least one fatal extension of the initial extension sets should not * return and for example reset the system. See section "System Termination * Procedure" in the RTEMS Classic API Guide. * * The following code is only executed in badly configured applications. */ _CPU_Thread_Idle_body( 0 ); } ``` -- View it on GitLab: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/30#note_109950 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
