Recent changes to bugs

#1305 SIMIA32: port_lock/port_unlock boolean flag breaks lock nesting, corrupts scheduler

Giovanni Di Sirio — Tue, 14 Apr 2026 18:43:33 -0000

status: open --> closed-invalid
assigned_to: Giovanni Di Sirio

#1305 SIMIA32: port_lock/port_unlock boolean flag breaks lock nesting, corrupts scheduler

Giovanni Di Sirio — Tue, 14 Apr 2026 18:42:53 -0000

• Thanks for the report and for the clear write-up.

I don’t think this is a SIMIA32 port bug. The important detail is that virtual
timer callbacks are still invoked in interrupt context, even though
chVTDoTickI() temporarily releases the kernel lock before calling the callback
and reacquires it afterward. That unlock/relock is only about reducing lock
hold time and jitter; it does not turn the callback into thread context.

Because of that, calling chSysLock() / chSysUnlock() from a virtual timer
callback is not valid. In that context the allowed forms are the I-class/X-
class APIs, not the S-class ones. With CH_DBG_SYSTEM_STATE_CHECK enabled,
tripping a state violation there is expected and is actually the debug checker
doing its job.

So the proposed change from a boolean port_irq_sts to a nesting counter would
be masking an API misuse rather than fixing the underlying issue. In this
port, that variable represents the current interrupt-enable state, not a
recursive lock depth.

The practical fix on the application side is to make sure code reached from a
virtual timer callback does not use S-class locking. If your logging path
currently wraps itself in something like CriticalSectionLocker based on
chSysLock() / chSysUnlock(), that wrapper is not suitable from a VT callback.
It should either use the ISR-safe variant for that path, or avoid calling that
code from timer callback context.

If useful, I can help review the specific callback/logging path and suggest
the right API substitutions.

SIMIA32: port_lock/port_unlock boolean flag breaks lock nesting, corrupts scheduler

Diego Frenoux — Mon, 13 Apr 2026 18:58:32 -0000

hey!, first bug report over here so i hope this is the correct place:

SIMIA32 port implements port_lock() / port_unlock() as boolean:

static inline void port_lock(void) {
  port_irq_sts = (syssts_t)1;
}
static inline void port_unlock(void) {
  port_irq_sts = (syssts_t)0;
}

This breaks when S-class and I-class locks are nested. ChibiOS virtual timer callbacks run with the lock released (chVTDoTickI calls chSysUnlockFromISR() before the callback and chSysLockFromISR() after). If the callback code uses chSysLock() / chSysUnlock() (S-class), the chSysUnlock() resets port_irq_sts to 0. When chVTDoTickI then calls chSysLockFromISR(), the state appears correct (0 -> 1), but the intermediate unlock corrupted the scheduler's view of the lock state.

Enabling CH_DBG_SYSTEM_STATE_CHECK catches the issue early as SV#6 (misplaced chSysLockFromISR)(at least on windows on our testing)

Reproduction

Any code that calls chSysLock() / chSysUnlock() from a virtual timer callback triggers this. In our case, a logging function uses CriticalSectionLocker (S-class) and is called from a timer callback via chVTDoTickI. (here: https://github.com/rusefi/rusefi/pull/9357)

Proposed fix

Use a nesting counter instead of a boolean:

static inline void port_lock(void) {
  port_irq_sts++;
}
static inline void port_unlock(void) {
  port_irq_sts--;
}
static inline void port_lock_from_isr(void) {
  port_irq_sts++;
}
static inline void port_unlock_from_isr(void) {
  port_irq_sts--;
}

we have this on our mirror of ChibiOs: https://github.com/rusefi/ChibiOS/pull/66

SIMIA32: port_lock/port_unlock boolean flag breaks lock nesting, corrupts scheduler

Diego Frenoux — Mon, 13 Apr 2026 18:58:32 -0000

Ticket 1305 has been modified: SIMIA32: port_lock/port_unlock boolean flag breaks lock nesting, corrupts scheduler
Edited By: Giovanni Di Sirio (gdisirio)
Status updated: 'open' => 'closed-invalid'
Owner updated: None => 'gdisirio'

OSLIB Jobs Queues: return JOB_NULL descriptors to the free pool

Giovanni Di Sirio — Wed, 18 Mar 2026 18:27:20 -0000

The OSLIB jobs dispatcher was leaking job descriptors on the JOB_NULL control
path.

In both chJobDispatch() and chJobDispatchTimeout(), a fetched descriptor was
returned to the guarded pool only when jobfunc != NULL. When a null job was
used as the documented worker shutdown signal, the dispatcher returned
MSG_JOB_NULL but did not release the descriptor back to the free pool.

Impact:

each null shutdown job permanently consumed one descriptor
repeated worker shutdown cycles could exhaust the queue
disposal-time checks did not detect the loss because the queue could still
appear idle

The fix:

always return the fetched descriptor to the guarded pool, including the
MSG_JOB_NULL path
add a regression test that posts null shutdown jobs, waits for the workers
to exit, then verifies:
- the guarded pool counter is back to JOBS_QUEUE_SIZE
- the mailbox has no pending jobs

serialize ref duplication and harden dynamic object size calculations

Giovanni Di Sirio — Wed, 18 Mar 2026 14:57:35 -0000

The OSLIB factory needed two safety fixes.

First, chFactoryDuplicateReference() was incrementing object reference
counters without using the factory lock, while create/find/release paths were
serialized. This created a race against final release and object reclamation.

Second, the heap-backed factory creators (Buffer, Mailbox, ObjectsFIFO, Pipe)
were performing unchecked add/multiply/alignment arithmetic when computing
allocation sizes. Extreme input values could overflow those calculations
before allocation, leading to undersized objects and out-of-bounds
initialization.

The fix:

makes chFactoryDuplicateReference() a locked API
adds checked size helpers for add/multiply/alignment operations
rejects overflowing size requests before allocation

harden memcore/heap boundary checks against arithmetic overflow

Giovanni Di Sirio — Wed, 18 Mar 2026 14:43:22 -0000

The OSLIB allocators need stronger bounds handling on arithmetic edge cases.

Two issues were addressed:

chCoreAllocFromBaseI() and chCoreAllocFromTopI() in chmemcore.c were
performing derived-address arithmetic before validating the request. With
extreme size or offset values, this could rely on out-of-range pointer
arithmetic before the guard code rejected the allocation.
chHeapAllocAligned() in chmemheaps.c rounded size with MEM_ALIGN_NEXT()
before checking for overflow. Near-SIZE_MAX requests could wrap during
rounding, derive an invalid pages count, and corrupt heap metadata during
block splitting.

The fix moves memcore calculations into integer space (uintptr_t) until bounds
are verified, and adds an explicit overflow check before converting heap
request size into allocation pages.

Fix priority inheritance through prioritized message queues

Giovanni Di Sirio — Wed, 18 Mar 2026 13:10:28 -0000

When CH_CFG_USE_MESSAGES_PRIORITY is enabled, the PI walk in chMtxLockS() boosts the priority of a thread blocked in CH_STATE_SNDMSGQ but does not re-enqueue it in the receiver's msgqueue, preserving the priority inversion.

Root cause: u.sentmsg and u.wtobjp alias in the u union, so there is nowhere to store the back-pointer to the receiver's queue while the sender is waiting.

chMsgSend missing rdymsg assignment causes spurious NULL return from chMsgWaitTimeoutS

Giovanni Di Sirio — Wed, 18 Mar 2026 11:45:35 -0000

chMsgSend wakes a receiver thread blocked in CH_STATE_WTMSG via chSchReadyI without first setting tp->u.rdymsg = MSG_OK. This leaves a stale value in rdymsg from a previous operation.

#1297 CMSIS osMessage const buffer

Giovanni Di Sirio — Wed, 18 Mar 2026 11:10:39 -0000

Fixed in Repository: False --> True