ZED SDK 5.5.0: Heap corruption in saveAreaMap() with GEN_3 tracking on longer sessions

Software C++
,
1

Hi Stereolabs team,

We’ve been encountering a reproducible heap corruption issue with ZED SDK 5.5.0 when calling sl::Camera::saveAreaMap() after longer positional tracking sessions using GEN_3 with area memory enabled.

Our setup uses a ZED X Mini camera connected to a Jetson Orin NX. During recent drone flight testing, we noticed that longer flights consistently crashed during shutdown with errors such as:

malloc(): invalid next size (unsorted)
malloc(): mismatching next->prev_size (unsorted)
double free or corruption (!prev)

Across 28 recorded sessions, all 19 successful shutdowns had fewer than approximately 9,800 tracked frames, while all 9 crashes occurred after approximately 10,900 frames. In every crash, the .area file was left at 0 bytes.

Investigation and reproduction

Initially, we suspected an issue with our application’s shutdown sequence, GStreamer buffer handling, or SVO recording. However, we’ve since isolated the issue using a minimal (~70-line) C++ application that links only against libsl_zed. I’ve attached it in this post.

sdk_area_repro.cpp (3.6 KB)

The reproducer opens a recorded SVO, enables GEN_3 positional tracking with area memory, processes a specified number of frames, and calls saveAreaMap().

Using the exact same SVO, we consistently get:

  • 8,000 frames: Successful export, 22.6 MB area map.
  • 9,000 frames: Successful export, 26.7 MB area map.
  • 10,000 frames: SIGABRT inside saveAreaMap(), 0-byte area map.
  • 11,500 frames: SIGABRT inside saveAreaMap(), partially written area map.
  • 12,888 frames (full SVO): SIGABRT inside saveAreaMap(), 0-byte area map.

The crash occurs before saveAreaMap() returns, and we’ve reproduced it both with and without GDB.

We also tested with glibc’s malloc checking enabled, which produced free(): invalid pointer inside the same SDK call chain.

Interestingly, a separate live-camera test successfully exported an area map after 11,722 frames while observing a mostly static scene. This suggests the issue may depend on accumulated area-memory or landmark state rather than frame count alone.

Heap investigation

We captured a core dump from one of the crashes and inspected the corrupted heap region.

The next heap chunk header appeared to have been overwritten by a contiguous sequence of what looks like SDK visual-feature/landmark records, containing feature IDs, pixel coordinates, bearing vectors, and binary descriptors.

The corruption occurs within SDK-internal code invoked by saveAreaMap(). Without SDK debugging symbols, we couldn’t determine whether this is a buffer overflow or use-after-free.

Questions

  1. Is this a known issue with GEN_3 area-memory export in SDK 5.5.0, and has it been addressed in a newer release?
  2. Are there known internal limits on accumulated landmarks, features, or area-memory state?
  3. Is calling saveAreaMap() periodically during active positional tracking supported? We’re considering this as a potential workaround for longer sessions.
  4. Are there any recommended settings or alternative approaches for safely exporting area maps after extended tracking sessions?

I’ve attached the minimal C++ reproducer, which uses the same SDK initialization and positional tracking parameters as our application.

We can also provide the failing SVO and GDB backtrace privately if that would help your team reproduce and investigate the issue.

Thanks!