Hi Stereolabs team,
We’re hitting a sporadic but reproducible segmentation fault that originates entirely inside libsl_zed.so, in the GEN_3 positional-tracking / SLAM pipeline. I’d like to know whether this is a
known issue and whether SDK 5.3 addresses it before we plan an upgrade.
Environment
- ZED SDK 5.1.1
- Cameras: ZED X and ZED X Mini, firmware 2001, resolution 1920×1200
- Input mode: network streaming — the cameras are attached to a Jetson and consumed on a separate x86_64 host via InitParameters::input::setFromStream(…)
- Host OS: Ubuntu 22.04, x86_64
- coordinate_system = RIGHT_HANDED_Z_UP_X_FWD, coordinate_units = METER
- Positional tracking: POSITIONAL_TRACKING_MODE::GEN_3, area memory enabled, IMU fusion disabled, pose smoothing disabled, depth_min_range = 0.20 m
- depth_mode = NEURAL_LIGHT on the tracked camera
- Grab rate ~15 FPS
Our usage (no SDK threading tricks)
For each camera we run a single dedicated thread that calls grab(), then retrieveImage() / retrieveMeasure(), and getPosition() for the camera that has positional tracking enabled. Only one
camera in our setup enables positional tracking, and that is the only camera that ever crashes.
Symptom
The process runs normally for a long, variable time — anywhere from ~20 minutes to ~2 hours — then dies with SIGSEGV. The fault always occurs on an internal SDK SLAM thread
(hybrid_tracker::SlamManager::run), never on our own grab/retrieve thread. It is strongly correlated with periods where the camera stream is unstable (we frequently see frames unavailable from
the stream around the crash window), which suggests the tracker is being fed degenerate/sparse data.
Backtrace (captured with gdb, identical across multiple crashes)
Thread “sensor_bundle_z” received signal SIGSEGV, Segmentation fault.
0x00007ffff0825cb5 in Eigen::JacobiSVD<Eigen::Matrix<double, -1, -1, 1, -1, -1>, 2>::compute(…) [clone .isra.0]
from /usr/local/zed/lib/libsl_zed.so
#0 Eigen::JacobiSVD<Eigen::Matrix<double, -1, -1, 1, -1, -1>, 2>::compute(…)
#1 Eigen::BDCSVD<Eigen::Matrix<double, -1, -1, 1, -1, -1> >::compute(…)
#2 sl_ceres::internal::CovarianceImpl::ComputeCovarianceValuesUsingDenseSVD()
#3 sl_ceres::internal::CovarianceImpl::Compute(…)
#4 hybrid_tracker::MultiViewGeometry::ceresPnP(…)
#5 hybrid_tracker::VisualFrontEnd::computePose(bool, double)
#6 hybrid_tracker::VisualFrontEnd::trackMono(…)
#7 hybrid_tracker::VisualFrontEnd::visualTracking(…)
#8 hybrid_tracker::SlamManager::run()
#9 tracking::HybridTracker::trackStereo(unsigned int, sl::Mat const&, sl::Mat const&, CUevent_st*)
Register state at the fault
rax = 0, rbx = 0, and the faulting instruction is movsd (%rbx),%xmm0 — i.e. a null-pointer dereference inside the dense-SVD covariance computation. This looks consistent with the PnP covariance
step (ComputeCovarianceValuesUsingDenseSVD) being handed an empty/degenerate matrix, which Eigen’s SVD then dereferences as null.
Questions
- Is this a known crash in the GEN_3 SLAM / PnP covariance path?
- Are the covariance-related and “corrupted frame” fixes in 5.1.2 / 5.2 / 5.3 expected to cover this, or is it a separate issue?
- Is there a runtime workaround on 5.1.1 (e.g. a tracking parameter) to avoid the covariance computation when the visual input is degenerate, short of disabling positional tracking entirely?
- Given that our input is a network stream that can drop frames, is there recommended handling so the tracker degrades gracefully instead of feeding a degenerate problem into the covariance SVD?
Happy to provide additional logs, an SVO capture, or a fuller thread apply all bt if useful. Thanks!