dangernoodle-io / breadboard / 30588886189

97%

push

github

fix: shrink httpd worker task frames via bb_data shared scratch pair (#1152)

Root cause (hardware-confirmed, controlled A/B): the httpd worker task
stack-canary panics on POST /api/reboot 5/5 at CONFIG_BB_HTTP_TASK_STACK_SIZE
=6144, 0/5 at 16384. Raising the stack was rejected as the fix -- the five
bb_data-fed route handlers each hand-rolled their own
`char body[N+1]; char parse_scratch[3072];` stack locals, stacking up to
~5.5KB of a single handler's own frame on top of the rest of the httpd call
chain.

Design (user-approved): an additive, callee-owned bb_data_scratch_acquire()/
_release() pair inside bb_data, backed by one shared file-scope static
buffer (body 1025B + parse_scratch 3072B). bb_data_apply()'s existing
caller-owned-buffers signature/contract is unchanged. Safety rests on the
proven invariant that ESP-IDF's httpd dispatches exactly one synchronous
handler at a time on its single worker task; the SSE async path (the sole
async-handler caller in this codebase) never calls this pair, since it
renders on a separate broadcaster task. A debug-build assert() traps a
future reentrant acquire loudly; it's compiled out under BB_DATA_TESTING so
a host test can exercise the fail-closed BB_ERR_INVALID_STATE return
directly.

Migrated the five call sites: reboot_handler (bb_system_routes.c),
wifi_patch_handler (bb_wifi_http_routes.c), factory_reset_handler and
storage_delete_handler (bb_storage_http_routes.c), and
bb_ota_check_config_post_handler (bb_ota_check_common.c). Removed their
now-dead per-file PARSE_SCRATCH_BYTES defines/boilerplate.

DWARF frames (xtensa esp32, examples/smoke), before -> after:
reboot_handler 3504 -> 192, wifi_patch_handler 3600 -> 288,
storage_delete_handler 5552 -> 1456, bb_ota_check_config_post_handler
5312 -> 2192 (factory_reset_handler is not compiled into smoke).

Net device RAM cost (review finding 2, measured on-branch): this is NOT a
net RAM saving -- the per-handler frame reductions buy headroom INSIDE the
exis... (continued)

7979 of 8582 branches covered (92.97%)

Branch coverage included in aggregate %.

30 of 30 new or added lines in 2 files covered. (100.0%)

13568 of 13723 relevant lines covered (98.87%)

2610.47 hits per line