uorb_listener's %pB debug printing (orb_info() -> lib_bsprintf()) does
real floating-point-to-string conversion synchronously, in the
listener's own task -- not a lightweight pointer dump. With
CONFIG_LIBC_PRINT_EXTENSION off, %pB just prints a raw pointer and the
default CONFIG_UORB_STACKSIZE (DEFAULT_TASK_STACKSIZE, 2048 on most
configs) is plenty. With it on, decoding a topic's float fields through
this path silently overflows a 2048-byte stack -- confirmed on real
hardware (ESP32-S3, one push every ~10-20ms from two subscribed
topics): uorb_listener hangs completely after printing only a partial
topic name, no panic, no stack dump, nothing -- because
CONFIG_SCHED_STACKGUARD/CONFIG_STACK_COLORATION aren't on by default
either, so there's no guard to catch the overflow before it corrupts
adjacent memory.
Raising the default only when CONFIG_LIBC_PRINT_EXTENSION is set (not
unconditionally, and not keyed off CONFIG_DEBUG_UORB specifically,
since anything else that selects the same libc extension hits the same
path) keeps the common case -- raw pointer output, small stack --
exactly as before, and only pays for the extra stack when the feature
that needs it is actually enabled.
4096 was verified sufficient (tested against 2048, which reproduces
the hang, and 8192, which also works but wastes RAM); reproduced
cleanly across multiple fresh boots.
Note: this default only applies when CONFIG_UORB_STACKSIZE has never
been explicitly recorded in .config. Like any Kconfig int default,
flipping CONFIG_LIBC_PRINT_EXTENSION on in an existing .config that
already has an explicit CONFIG_UORB_STACKSIZE value won't retroactively
raise it; the value has to be re-picked (e.g. via a fresh olddefconfig
after removing the stale line, or manually).
Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
34ca2a5ed8