dangernoodle-io / breadboard / 30176490171

97%

push

github

fix: fail-fast bb_lock on uninitialized handle + add bb_lock_once_ensure helper (#1082)

bb_lock_init() can fail under transient heap pressure, leaving a
zero-inited bb_lock_t whose bb_lock_lock()/trylock()/unlock() previously
handed a NULL/garbage backend handle straight to the platform mutex
primitive -- undefined behavior that permanently bricked every future
caller of that lock. Chosen as a single fix: prefixed as `fix:` (not
`feat:`) because the fail-fast floor is the change that ships to every
existing bb_lock_t call site; the new bb_lock_once_ensure() helper rides
along in the same commit so the new error return never exists without a
recovery path, per the approved design.

- bb_lock_lock()/trylock()/unlock() (both host and ESP-IDF backends) now
  check bb_lock_initialized and return BB_ERR_INVALID_STATE without
  touching the backend handle, logging once per lock instance (new
  bb_lock_invalid_logged field) so a hot-path caller looping on the same
  broken lock cannot flood the log, while a distinct broken lock still
  gets its own one-time log
- new bb_lock_check_usable() (both backends) requires
  bb_lock_initialized && !bb_lock_destroyed before touching the backend
  handle -- closes a hole where lock()/trylock()/unlock() called after a
  successful bb_lock_destroy() (which never clears bb_lock_initialized,
  by design: init/destroy is one-shot, not re-armable) fell through to
  xSemaphoreTake(NULL, ...) on ESP-IDF or a destroyed pthread_mutex_t on
  host; covered by three new after-destroy tests
  (test_bb_lock_lock/trylock/unlock_after_destroy_returns_invalid_state)
- add bb_lock_is_initialized() (bb_lock.h) as the sentinel re-check idiom
- add bb_lock_once_ensure() (new bb_lock_once.h/.c, portable TU shared by
  both platforms) composing bb_lock_init() with bb_once_run_fallible() so
  a transient init failure retries instead of latching permanently done,
  mirroring the bb_wifi_ping/bb_timer/bb_mdns pattern B1-524 established
- bb_core... (continued)

7770 of 8375 branches covered (92.78%)

Branch coverage included in aggregate %.

24 of 24 new or added lines in 3 files covered. (100.0%)

13254 of 13412 relevant lines covered (98.82%)

2581.16 hits per line