On Jetson Orin NX with ZED SDK 5.5.0, a C++ client opens two ZED X One GS cameras sequentially and calls only grab(). The first process exits cleanly; reopening the same binary in the same boot can stall both grab() calls and abort during SDK/Argus recovery with malloc(): unaligned tcache chunk detected.
Reproduction:
- Start two ZED X One GS cameras after a boot with no other camera client running.
- Verify both workers joined and both
close()calls returnedSUCCESS, and the process exited normally. 3. Run the identical command again in the same boot. First reopen aborted spontaneously. In some camera configurations a second reopen is required, so repeat once more if needed.
malloc(): unaligned tcache chunk detected
Program received signal SIGABRT
Abort/recovery thread:
__GI___libc_malloc(bytes=48)
libnvargus_socketclient.so
sl::ArgusCamera::open(...)
sl::ArgusCamera::reboot(bool)
sl::ArgusCamera::control()
Blocked capture threads include:
sl::ArgusCamera::readSingle(...)
sl::GMSLInput::waitForNewFrame(int)
sl::CameraOne::grab(...)
```
Environment:
Linux tonu-jetson 6.8.12-1021-tegra-wg #2 SMP PREEMPT Fri Sep 4 15:35:30 EEST 2026 aarch64 aarch64 aarch64 GNU/Linux
# R39 (release), REVISION: 2.1, GCID: 46758480, BOARD: generic, EABI: aarch64, DATE: Fri Aug 7 05:54:22 AM UTC 2026
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia
f4d08c76ee844977358da3cb738e8c5daae15c70a83aa25e46ff76ae76e731b7 /usr/local/zed/lib/libsl_zed.so
f63be44ea6bdad92ed00d19c23c9ff30ea2dc4d9847e93b562d4aa1c486687b4 /usr/lib/aarch64-linux-gnu/nvidia/libnvargus_socketclient.so
e091c2e97a83123a7d5e7d482c2f69e41eecfac97b44fcbd129560561beffb4b /usr/sbin/nvargus-daemon
Code:
#include <sl/CameraOne.hpp>
#include <thread>
int main() {
sl::CameraOne a, b;
sl::InitParametersOne p;
p.camera_resolution = sl::RESOLUTION::SVGA;
p.camera_fps = 15;
p.input.setFromCameraID(0);
if (a.open(p) != sl::ERROR_CODE::SUCCESS) return 1;
p.input.setFromCameraID(1);
if (b.open(p) != sl::ERROR_CODE::SUCCESS) return 2;
auto grab = [](sl::CameraOne* camera) {
for (int i = 0; i < 360; ++i)
camera->grab();
};
std::thread ta(grab, &a);
std::thread tb(grab, &b);
ta.join();
tb.join();
a.close();
b.close();
}
All ~ 20 trials contained CSI/V4L2-related errors during camera discovery/setup. About a few failing trials contain a second occurrence burst after the automatic nvargus-daemon stop/start. Because the initial burst also occurs in most passing trials, the messages are relevant evidence but are not proof that CSI caused the heap corruption.
2026-09-23T15:51:52.624312+03:00 ... (NvCamV4l2) Error 0x000a000e: V4L2Device not available ... findDevice(), line 261
2026-09-23T15:51:52.624369+03:00 ... (NvOdmDevice) Error 0x000a000e: ... V4L2SensorViCsi.cpp, function initialize(), line 114
2026-09-23T15:51:52.624369+03:00 ... SCF: Error 0x00000004: Sensor could not be opened ... getSourceFromGuid(), line 726
2026-09-23T15:51:53.242440+03:00 ... (fusa) Error: BadValue nullptr in string in: fusaCsiStreamHandler.cpp 185
2026-09-23T15:52:12.199903+03:00 ... systemd[1]: Stopping nvargus-daemon.service - Argus daemon...
2026-09-23T15:52:13.246223+03:00 ... (NvCamV4l2) Error 0x000a000e: V4L2Device not available ... findDevice(), line 261
2026-09-23T15:52:13.246223+03:00 ... (NvOdmDevice) Error 0x000a000e: ... V4L2SensorViCsi.cpp, function initialize(), line 114
2026-09-23T15:52:13.246223+03:00 ... SCF: Error 0x00000004: Sensor could not be opened ... getSourceFromGuid(), line 726
2026-09-23T15:52:15.725266+03:00 ... (fusa) Error: BadValue nullptr in string in: fusaCsiStreamHandler.cpp 185
This may share the underlying defect reported in topic 11720, but it is not a confirmed duplicate. Evidence demonstrates an unsanitized SDK 5.5.0 same-boot reopen crash with heap corruption and CSI/Argus recovery errors. Please merge or cross-reference the cases if engineering confirms a common root cause.