ESP32-S3: HTTPD task stack overflow during Music Assistant playback; increasing config.stack_size appears to resolve

[jonlove234]

Summary

I'm seeing reproducible crashes on an ESP32-S3 running the SendSpin ESP integration. The crash is a FreeRTOS stack overflow in the httpd task.

The overflow occurs while streaming from Music Assistant. Increasing the HTTP server task stack from the ESP-IDF default to 16 KB appears to eliminate the crash (testing is still ongoing).

Environment
sendspin-cpp: 0.7.0 (bundled with ESPHome)
ESPHome: 2026.7.3
ESP-IDF: 5.5.5
Music Assistant: 2.9.9
MCU: ESP32-S3
Symptoms

Before every crash I consistently see protocol warnings such as:

W (...) sendspin.protocol: Ignoring field 'track_duration': expected integer in [0, 4294967295]
A few minutes later:

***ERROR*** A stack overflow in task httpd has been detected.
The decoded backtrace is:

panic_abort
esp_system_abort
vApplicationStackOverflowHook
vTaskSwitchContext

The overflowing task is explicitly reported as httpd.

Investigation

SendspinWsServer::start() creates the HTTP server using:

httpd_config_t config = HTTPD_DEFAULT_CONFIG();
The code customizes several fields (task_priority, ports, callbacks, etc.) but leaves config.stack_size at the ESP-IDF default.

As a test, I modified src/esp/ws_server.cpp to set:

httpd_config_t config = HTTPD_DEFAULT_CONFIG();
config.stack_size = 16384;

After rebuilding and flashing, the device successfully:

starts the HTTP server
accepts SendSpin connections
completes the WebSocket handshake
connects to Music Assistant

and, so far, has not reproduced the previously frequent stack overflow. I'm continuing longer-term testing.

Question

Has anyone else observed HTTPD stack overflows on ESP32-S3 or with newer ESP-IDF versions?

If not, would it make sense to increase the default HTTPD task stack (or make it configurable) for the ESP implementation? It seems the current default may no longer provide enough headroom under real-world protocol handling.

I'm happy to provide additional logs or test proposed changes if that would be useful.

[jonlove234]

Example panic log:

[13:01:45][I][esp-idf:000][httpd]: W (373989) sendspin.protocol: Ignoring field 'track_duration': expected integer in [0, 4294967295]
[13:04:53][I][esp-idf:000][httpd]: W (562243) sendspin.protocol: Ignoring field 'track_duration': expected integer in [0, 4294967295]

[13:07:57]
***ERROR*** A stack overflow in task httpd has been detected.

Backtrace: 0x40380e49:0x3c234a40 0x40380e11:0x3c234a60 0x4038164e:0x3c234a80 0x40381eb7:0x3c234b00 0x403811dc:0x3c234b20 0x403811d2:0x00000000 |<-CORRUPTED

ELF file SHA256: bc9db1b43

Rebooting...
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4037de3e
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2820,len:0x1510
load:0x403c8700,len:0xccc
load:0x403cb700,len:0x2f48
entry 0x403c8914
I (24) boot: ESP-IDF 5.5.4 2nd stage bootloader
I (24) boot: Multicore bootloader
I (24) boot: chip revision: v0.2
I (24) boot: efuse block revision: v1.4
I (25) boot.esp32s3: Boot SPI Speed : 80MHz
I (25) boot.esp32s3: SPI Mode       : DIO
I (25) boot.esp32s3: SPI Flash Size : 4MB
...

[kahrendt]

Thanks for raising this! There are 2 things going on here:

1. [13:04:53][I][esp-idf:000][httpd]: W (562243) sendspin.protocol: Ignoring field 'track_duration': expected integer in [0, 4294967295] is a bug in aiosendspin/Music Assistant. It's sending a floating point number and the Sendspin spec specifies it should be an integer. I'm working on getting a PR to fix it there.
2. The stack overflow itself. When metadata is enabled, stack usage increases quite a bit due to some inefficiencies in my code.

I am trying to avoid increasing the stack size if possible. Could you please try out this branch https://github.com/Sendspin/sendspin-cpp/tree/httpd-stack-reduction? I refactored the code and it should reduce the stack usage quite a bit. It also has a high water log marker that will log the task's highest stack usage point whenever that changes. I'm hoping we will have a lot of headroom after the other changes.

Edit: @jonlove234 After testing, could you report if the crash still happens? Even if it doesn't, could you report what the high water stack usage is after awhile? It should only log it whenever it changes, so it may hit a high point early on in the logs even if music plays awhile. In general, track changes will cause this type of stack overflow to happen more often, so you could maybe speed up the process by changing tracks quickly.

[kahrendt]

I'm investigating the Ignoring field 'track_duration': expected integer in [0, 4294967295] bit more, and I'm now not confident a floating point number is sneaking in over the wire. Can you tell me how you are playing the audio in Music Assistant? What provider are you using? What type of track is it; i.e., a long run radio stream or a typical song? 4294967295 ms is around 49.7 days, so something falling out of those bounds seems kind of odd!

[bdraco]

Seeing this on an Apollo CAST-1 as well

[14:03:06.145][I][runtime_stats:116]:   main_loop_overhead_section: before=87.3ms, tail=22.4ms, inter_component=280.9ms
[14:03:07.303][D][esp-idf:000]: I (256577) sendspin.client: loop profile: ticks=93 conn=3637us cur=670us burst=2379us ring=366us roles=291us lockwait=488us copy=830us
[14:03:17.368][D][esp-idf:000]: I (266642) sendspin.client: loop profile: ticks=94 conn=3623us cur=679us burst=2571us ring=351us roles=289us lockwait=492us copy=837us
[14:03:27.372][D][esp-idf:000]: I (276646) sendspin.client: loop profile: ticks=92 conn=3490us cur=679us burst=2082us ring=273us roles=290us lockwait=456us copy=806us
[14:03:31.328][D][bluetooth_proxy:473]: Setting scanner mode to active
[14:03:31.328][D][esp32_ble_tracker:214]: Stopping scan.
[14:03:37.445][D][esp-idf:000]: I (286719) sendspin.client: loop profile: ticks=91 conn=3460us cur=657us burst=1212us ring=255us roles=270us lockwait=474us copy=808us

[14:03:39.825]***ERROR*** A stack overflow in task httpd has been detected.


[14:03:39.825]Backtrace: 0x403865e9:0x3fcdc0f0 0x403865b1:0x3fcdc110 0x40386dfa:0x3fcdc130 0x40387663:0x3fcdc1b0 0x40386988:0x3fcdc1d0 0x4038697e:0x3c18bf42 |<-CORRUPTED
WARNING Found stack trace! Trying to decode it
WARNING Decoded 0x403865e9: panic_abort at /COMPONENT_ESP_SYSTEM_DIR/panic.c:477
WARNING Decoded 0x403865b1: esp_system_abort at /COMPONENT_ESP_SYSTEM_DIR/port/esp_system_chip.c:87
WARNING Decoded 0x40386dfa: vApplicationStackOverflowHook at /COMPONENT_FREERTOS_DIR/FreeRTOS-Kernel/portable/xtensa/port.c:573
WARNING Decoded 0x40387663: vTaskSwitchContext at /COMPONENT_FREERTOS_DIR/FreeRTOS-Kernel/tasks.c:3698 (discriminator 7)
WARNING Decoded 0x40386988: _frxt_dispatch at /COMPONENT_FREERTOS_DIR/FreeRTOS-Kernel/portable/xtensa/portasm.S:451
WARNING Decoded 0x4038697e: _frxt_int_exit at /COMPONENT_FREERTOS_DIR/FreeRTOS-Kernel/portable/xtensa/portasm.S:246

Probably the logging overhead on a non-main task.

[bdraco]

I thought about serializing the args in the task logging in logger, wrote a test implementation that works, and than decided to abandon it since ESP-IDF will switch to picolibc which will reduce the stack usage by more than 50% so the logging problem will go away in the next few weeks when we switch to ESP-IDF 6 anyways.

[bdraco]

side note: we were not able to optimize enough to avoid raising the web_sever_idf stack so we had to finally give up the optimization route and add 256 bytes in https://github.com/esphome/esphome/blob/f8b83cc8a21cc27e027a12cc4537d05757832e16/esphome/components/web_server_idf/web_server_idf.cpp#L144

[jonlove234]

Thanks, the stack high-water-mark logging is exactly what I needed. Been running the httpd-stack-reduction branch for a bit and have some info for you, plus answers to your questions.

How I'm playing it: Apple Music through Music Assistant, nothing fancy. I just hit play on a playlist from the MA panel in Home Assistant and let it run, so the crash happens naturally as one track ends and the next starts, not from anything I'm triggering by hand. The device is a Sonocotta Esparagus Echo (ESP32-S3) and it's a Sendspin player in MA, streaming FLAC 48k/16-bit, with the hub's task_stack_in_psram on. The tracks throwing the warning are just normal songs off a playlist, no radio streams or anything weird.

1. The track_duration warning isn't an occasional thing, it fires on basically every track change. Regular finite-length songs, every single time one starts. If a float's sneaking in, it's sneaking in for pretty much everything MA sends, not just streams. A few it fired on: The Weeknd "Save Your Tears", Alicia Keys "If I Ain't Got You", Oasis "Some Might Say". Happy to grab the raw JSON payload if you point me at where you'd want it logged.

Trimmed log from a couple of track changes (the warning lands right on the stream transition every time):

[httpd] D sendspin.client: Stream ended - player:1 artwork:0 visualizer:0
[httpd] D sendspin.client: Stream Started
[Sendspin] I sendspin.sync_task: Processed new codec header: flac, 48000 Hz, 2 ch, 16-bit
[httpd] W sendspin.protocol: Ignoring field 'track_duration': expected integer in [0, 4294967295]
S text_sensor: 'Track Title' >> 'Into You'
S text_sensor: 'Artist' >> 'Ariana Grande'
...
[httpd] W sendspin.protocol: Ignoring field 'track_duration': expected integer in [0, 4294967295]
S text_sensor: 'Track Title' >> 'I'm Yours'
S text_sensor: 'Artist' >> 'Jason Mraz'

2. Stack headroom is still really tight on this branch. Hasn't crashed yet, but the high-water-mark readings kept dropping over the session instead of settling. This is on the S3 with the task stack in PSRAM. So the leaner stack here is cutting it close for me, whereas my earlier manual 16 KB bump had more room. Makes me wonder if whatever handles that rejected track_duration field is eating into the depth.

D sendspin.ws_server: httpd task stack headroom: 1788 bytes    (at boot)
D sendspin.ws_server: httpd task stack headroom: 764 bytes     (streaming)
D sendspin.ws_server: httpd task stack headroom: 572 bytes     (after a track change)

[kahrendt]

Tracking it down, the track_duration float was a bug in Music Assistant 2.9.9 for Apple Music that has since been fixed. Sendspin/aiosendspin#311 fixes it so that no other provider can accidentally do this in the future.

The stack usage here does some improved with those changes, so I'm going to go with just #104 and not increase the default stack size at this time (572 bytes with the error logged still is ~14% of the task space already allocated, that seems like an okay margin on a stress tested warning). I will have to increase the stack size a bit for future encryption work, and I'll be sure to monitor the high water mark in my dev builds when doing testing. Please reopen this issue if you do you end up getting another stack overflow here (or open a new issue if that is more fitting!) Thanks again for reporting and testing @jonlove234!