dangernoodle-io / breadboard / 30518057528

97%

push

github

fix: migrate POST /api/reboot, PATCH /api/wifi, factory-reset off bb_http_json_obj_stream_t (#1148)

Three httpd task handlers built their JSON response with
bb_http_json_obj_stream_t, whose _buf field alone is 1024 bytes
(BB_HTTP_JSON_OBJ_BUF_SIZE), for a 1048-byte struct. Combined with the
request-parse frame (bb_data_apply's parse_scratch), this statically
overflows CONFIG_BB_HTTP_TASK_STACK_SIZE's default 6144-byte budget:
wifi_patch_handler's measured chain was 6576 bytes, reboot_handler's a
lower but still-crashing 5440 (observed on real hardware). Corruption of
the task's newlib _reent/pthread-TLS block then faults later inside
pthread_getspecific, in the send path rather than the handler that
actually caused it.

Migrates reboot_handler, wifi_patch_handler, and factory_reset_handler's
response emission (both its 202 success body and its two-path error
helpers) onto bb_http_serialize_stream() + a bb_serialize_desc_t, the
same low-stack-footprint pattern already used by the GET diag/wifi/ota
routes. The single-field {"error":"<msg>"} shape shared by all three
files' send_400/send_500/send_501/send_412 helpers is factored into one
new bb_http_serialize_send_error() (components/bb_http_server) rather
than re-hand-rolled three times, per the Consolidation convention.

Measured on an esp32 smoke build (xtensa-esp32-elf-readelf
--debug-dump=frames, DW_CFA_def_cfa_offset):
  reboot_handler:      4528 -> 3504 bytes
  wifi_patch_handler:  5664 -> 3600 bytes
  factory_reset_handler: 3344 bytes (not in the smoke build config
    pre-migration either, so no baseline to diff against)
storage_delete_handler (shares the migrated error helpers, but its own
response body was already on bb_http_serialize_stream before this PR)
is unchanged at 5552 bytes, confirming the shared-helper edit didn't
regress it.

No JSON shape, field order, or status code changes -- verified
byte-for-byte against the deleted bb_http_json_obj_stream_t call sites.
body[]/parse_scratch[]... (continued)

7973 of 8576 branches covered (92.97%)

Branch coverage included in aggregate %.

8 of 8 new or added lines in 1 file covered. (100.0%)

13540 of 13695 relevant lines covered (98.87%)

2655.92 hits per line