Crash in peer_default SCTP (sctp_add_ref / __atomic_fetch_add_1) when enable_data_channel = false (esp32s3)

[matiaspl]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

I expect the underlying apps not to crash with data_channels disabled.

Actual behavior (suspected bug)

When using esp_webrtc + peer_default on ESP-IDF v5.4.3 (target esp32s3), the device crashes in sctp_add_ref due to a LoadProhibited exception inside __atomic_fetch_add_1. The faulting address is always a low, invalid pointer (0x000005ac), suggesting a bad SCTP context/refcount pointer inside the prebuilt libpeer_default.a.

This happens only when .enable_data_channel = false. If I change the same config to .enable_data_channel = true, the crash disappears (same hardware, IDF, and server)

Error logs or terminal output

With .enable_data_channel = false, the device crashes:

  Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

  Core  1 register dump:
  PC      : 0x4038ae58  PS      : 0x00060230  A0      : 0x8038aa68  A1      : 0x3c2b2c20
  --- 0x4038ae58: __atomic_s32c1i_fetch_add_1 at .../components/newlib/port/xtensa/stdatomic_s32c1i.c:77
  A2      : 0x00000003  A3      : 0x01000000  A4      : 0x00000005  A5      : 0x3c23b688
  A6      : 0xe550d62c  A7      : 0x3fcdd29c  A8      : 0x00000018  A9      : 0x000005ac
  ...
  EXCCAUSE: 0x0000001c
  EXCVADDR: 0x000005ac
  ...
  Backtrace:
   0x4038ae55: __atomic_s32c1i_fetch_add_1 (stdatomic_s32c1i.c:77)
   0x4038aa65: __atomic_fetch_add_1        (stdatomic.c:31)
   0x4201a70b: sctp_add_ref                (/home/tempo/test/esp-webrtc/components/esp_webrtc/impl/peer_default/sctp/sctp.c:43)
   0x4201c6c0: sctp_incoming_data          (.../sctp/sctp.c:580)
   0x420153d0: peer_recv_streams           (.../peer_default/core/peer_default.c:1132)
   0x420154fe: peer_main_loop              (.../peer_default/core/peer_default.c:1223)
   0x4216d5c3: esp_peer_main_loop          (components/esp_peer/src/esp_peer.c:140)
   0x42011c46: pc_task                     (components/esp_webrtc/src/esp_webrtc.c:286)
   0x403823e5: vPortTaskWrapper            (.../freertos/portable/xtensa/port.c:139)

  EXCVADDR = 0x000005ac suggests that in sctp_add_ref, the context pointer used for refcounting is invalid (near zero), and this invalid pointer is passed
  to __atomic_fetch_add_1.

Steps to reproduce the behavior

1. Build esp-webrtc-solution with ESP‑IDF v5.4.3, target esp32s3
2. Use a config where:

• esp_webrtc_cfg_t.peer_cfg.enable_data_channel = false.
• peer_impl = esp_peer_get_default_impl().
• Signaling is WHIP or our intercom WebRTC signaling (esp_signaling_get_whip_impl() / esp_signaling_get_intercom_session_impl()).

3. Connect to a server that negotiates SCTP/data channels on the remote side.
4. Once the connection establishes and media/data begin flowing, the device crashes.

I use esp_webrtc_open() with peer_default similarly to whip_demo and doorbell_local.

Simplified config (webrtc_client.c):

esp_webrtc_cfg_t cfg = {
.peer_cfg = {
.audio_info = {
.codec = ESP_PEER_AUDIO_CODEC_OPUS,
.sample_rate = 16000,
.channel = 1,
},
.video_info = {
.codec = ESP_PEER_VIDEO_CODEC_NONE,
.width = 0,
.height = 0,
.fps = 0,
},
.audio_dir = ESP_PEER_MEDIA_DIR_SEND_RECV,
.video_dir = ESP_PEER_MEDIA_DIR_NONE,
.enable_data_channel = false, // <-- critical
.no_auto_reconnect = true,
},
.signaling_cfg = {
.signal_url = base_url,
.extra_cfg = &session_cfg,
.extra_size = sizeof(session_cfg),
},
.peer_impl = esp_peer_get_default_impl(),
.signaling_impl = esp_signaling_get_intercom_session_impl(),
};

Changing just .enable_data_channel = true (keeping everything else the same) makes the crash go away.

Project release version

latest

System architecture

ARM 64-bit (Apple M1/M2, Raspberry Pi 4/5)

Operating system

MacOS

Operating system version

Sequoia

Shell

ZSH

Additional context

Environment

• Repo: esp-webrtc-solution
• Solution: custom, but uses components/esp_webrtc + components/esp_peer as‑is)
• esp_webrtc version: 0.9.0 (from components/esp_webrtc/idf_component.yml)
• esp_peer version: 1.2.7 (from components/esp_peer/idf_component.yml)
• ESP‑IDF: v5.4.3
  Paths in logs:
  .../esp-idf-v5.4.3/components/newlib/stdatomic.c
  .../esp-idf-v5.4.3/components/newlib/port/xtensa/stdatomic_s32c1i.c
• Toolchain: xtensa-esp32s3-elf (esp‑14.2.0_20250730)
• Target: esp32s3
• Relevant config: CONFIG_STDATOMIC_S32C1I_SPIRAM_WORKAROUND=y
• esp_peer is using the prebuilt libpeer_default.a via:

add_prebuilt_library(${BASE_DIR} "${CMAKE_CURRENT_SOURCE_DIR}/libs/${IDF_TARGET}/libpeer_default.a" ...)

[TempoTian]

I see it. I will provide one lib to fixed this issue. But from the log seems that even SDP not include data channel, but peer still send SCTP message cause issue. I will keep current behavior just resist peer SCTP request. Does it acceptable?

[TempoTian]

Can use following lib to do test replace to esp_peer/lib/esp32s3
libpeer_default.zip