#1309 RT trace halt event can dereference uninitialized trace buffer before kernel startup completes

[Giovanni Di Sirio]

Description:

When RT tracing is enabled, chSysHalt() logs halt events through
__trace_halt(). However, chSysHalt() is documented as callable from any system
state, including before chSysInit() completes.

The trace buffer is initialized in chInstanceObjectInit() via
__trace_object_init(), before the system transitions to ch_sys_running. If a
halt occurs earlier, for example from HAL/board initialization or an early
assertion, __trace_halt() can access oip->trace_buffer.ptr while it is still
zero-initialized, causing a NULL dereference instead of preserving the
original halt reason.

Trigger Conditions:

• CH_DBG_TRACE_MASK != CH_DBG_TRACE_MASK_DISABLED
• chSysHalt() is called before ch_system.state == ch_sys_running
• Typical path: halInit() or board/clock initialization hits osalSysHalt() /
  osalDbgAssert() before chSysInit() initializes the RT instance trace buffer

Impact:
The system may fault or stop on a NULL dereference while processing the halt
trace event, masking the original failure reason and making early startup
failures harder to diagnose.

Fix:
Guard halt trace emission with the system lifecycle state. __trace_halt()
should only write a trace record when ch_system.state == ch_sys_running,
because at that point the trace buffer has been initialized.

Affected Branches:

• trunk
• stable 21.11.x