DRIVE OS Version: Provide DRIVE OS version. Example: 7.2.5
Issue Description: On DriveOS 7.2.5 / DriveWorks 7.2.5, live Valeo GMSL through
sample_camera_logger aborts with glibc stack-protector failure (exit 134)
immediately after SIPL camera init resumes.
The same CAM1 attach (2× IMX728 + 1× IMX623, csi-gh) streams under stock
nvsipl_camera offscreen with 0 drops.
The same rig on DriveOS 7.0.3 sample_camera initializes three camera.gmsl clients and
writes /tmp/bench-val-cam1.mp4.
sample_camera_logger
timeout --signal=TERM --kill-after=8s 25s sample_camera_logger \
--rig=$HOME/valeo-imx728x2-imx623x1-cam1.json \
--offscreen=1 \
--profiling=0 \
--time-duration=12 \
--loglevel=INFO
[18-08-2026 13:38:04] [CameraLogger] DW SAL started
[18-08-2026 13:38:04] Main: Setting Image Pool.
[18-08-2026 13:38:04] Setting Image Pool for CameraOutputType: 1
[18-08-2026 13:38:04] Setting Image Pool for CameraOutputType: 1
[18-08-2026 13:38:04] Setting Image Pool for CameraOutputType: 1
[18-08-2026 13:38:04] CameraClient::bootstrap() already completed, skipping
[18-08-2026 13:38:04] Custom FSYNC is disabled
[18-08-2026 13:38:05] CameraClient::init() resume call success.
[18-08-2026 13:38:05] CameraClient::init() resume call success.
[18-08-2026 13:38:05] CameraClient::init() resume call success.
*** stack smashing detected ***: terminated
timeout: the monitored command dumped core
EXIT:134
thor-a-sample_camera_logger-cam1.txt (10.1 KB)
valeo-imx728x2-imx623x1-cam1.json.txt (2.2 KB)
nvsipl_camera (working demonstration that sensors and NVSIPL is just fine)
nvsipl_camera -c DevKit_Valeo_IMX728_x2_IMX623_x2_5Des_CPHY_x4 \
-m '0x0000 0x0000 0x0000 0x0000 0x1110' \
-r 10 -s -v 1 -Z
Sensor16 Frame captured: 200 Frame drops: 0 Frame discontinuities: 0 Frames authenticated: 0 Frames failed to authenticate: 0 Frames authenticated as Out Of Order: 0
Sensor17 Frame captured: 200 Frame drops: 0 Frame discontinuities: 0 Frames authenticated: 0 Frames failed to authenticate: 0 Frames authenticated as Out Of Order: 0
Sensor18 Frame captured: 200 Frame drops: 0 Frame discontinuities: 0 Frames authenticated: 0 Frames failed to authenticate: 0 Frames authenticated as Out Of Order: 0
SUCCESS
EXIT:0
FYI this is using a custom NVSIPL platform definition created to allow mixing the specific set of sensors. This platform definition is omitted here as it is irrelevant to the failure (in DriveWorks) and the nvsipl_camera test clearly works fine.
Dear @david.cattley ,
When you run the cameras individually, is sample_camera working? Any insights on if the issue occurring with any camera combination?
I’m also seeing this on my side with a single camera in a rig.json. nvsipl_camera works with no frame drops, but I see the same stack smashing detected error when running with either sample_camera_logger or recorder.
rig_test.json.txt (769 Bytes)
recorder_output.txt (8.1 KB)
sudo /usr/local/driveworks/tools/capture/recorder ~/rig_test.json
...
[18-08-2026 17:26:23] CameraMaster: calling init
[18-08-2026 17:26:23] EncoderNVMediaBase: Setting encode on instance 0
[18-08-2026 17:26:23] EncoderNVMediaBase: setRateControlParameters exit successfully
[18-08-2026 17:26:23] EncoderNVMediaBase: qualityParameter exit successfully
[18-08-2026 17:26:23] EncoderNVMediaBase: setRateControlParameters exit successfully
[18-08-2026 17:26:23] EncoderNVMediaBase: setEncoderNVMediaConfigH264 exit successfully
[18-08-2026 17:26:24] SYNC ENTRIES
[18-08-2026 17:26:24]
[18-08-2026 17:26:24] MP4Writer: finishing movie without any samples.
[18-08-2026 17:26:24] MP4Writer: finishing movie without any samples.
Rig: rig_test.json NewSink: /dev/null
Press s<Enter> to start, just <Enter> to see progress, q<Enter> to quit.
[18-08-2026 17:26:24] SIPLNotifier: INVALID NOTIFICATION type: 223
[18-08-2026 17:26:24] SIPLNotifier: Notification received from pipeline index:0 of type: INVALID NOTIFICATION
*** stack smashing detected ***: terminated
Aborted
Can you change the camera group and see if it is working? Please share the complete log for sample_camera for single camera?
I’ve attached the output I see when running sample_camera_logger:
$ sudo /usr/local/driveworks/bin/sample_camera_logger --rig=/home/may/rig_test.json --offscreen=1 --profiling=0 --time-duration=1 --loglevel=VERBOSE
sample_camera_logger_output.txt (16.4 KB)
I see the same thing on csi-gh and csi-ab. What do you mean by change the camera group?
No. It does not matter 1, 2, or 3 cameras. It always terminates in a stack smash message.
In this test sample_camera was cross-compiled in the docker and scp’ed to the target then run:
/home/nvidia/sample_camera \
--rig=/home/nvidia/valeo-imx728-cam1-link3.json \
--offscreen=1 \
--profiling=0
Rig File: valeo-imx728-cam1-link3.json.txt (809 Bytes)
the log output ended with:
[13-08-2026 21:48:09] SIPLDeviceBlockNotificationHandler: Cannot set thread name to EventQueue, return status: 34
[13-08-2026 21:48:09] CameraMaster: MAX96172_FUSA_NV_CUSTOM interface found
[13-08-2026 21:48:09] CameraMaster: No async SIPL init future found - starting async init now (fallback path). This can happen if dwSAL_start() was not called before dwSensor_start()
[13-08-2026 21:48:09] CameraMaster::waitAndVerifyAsyncInit: Future not valid, nothing to wait for
[13-08-2026 21:48:09] CameraClient #0 ImageQueue timeout for clientType: ISP
[13-08-2026 21:48:09] CameraClient #0: No frame from ISP queue, timeoutUs: 33333
[13-08-2026 21:48:09] CameraClient #0 got event: 3
[13-08-2026 21:48:09] CameraClient #0 got event: 3,from frame number: 0,eventdata frameNumber: 0,event number: 1
*** stack smashing detected ***: terminated
timeout: the monitored command dumped core
sample_camera-1cam-20260814.log (31.7 KB)
It seems consistent between (cross compiled) sample_camera and (in-box) sample_camera_logger
I am able to reproduce the issue with sample_camera with valeo camera using below rig. I will file a bug and update you on this?
Do you have any other cameras to test?
{
"rig": {
"sensors": [
{
"name": "camera:sample0",
"nominalSensor2Rig_FLU": {
"roll-pitch-yaw": [
0.0,
0.0,
0.0
],
"t": [
1.8621,
-0.1939,
1.3165
]
},
"parameter": "camera-name=V1SIM728MPRU4120ND1,disable-custintf=1,disable-auth=1,interface=csi-ab,skip-eeprom=1,CPHY-mode=1,link=0,fifo-size=8,output-format=raw+processed,async-record=1,deserializer=MAX96724_Fusa_nv,file-buffer-size=16777216,format=mp4",
"properties": {
"COMMENT": "Nominals",
"Model": "ftheta",
"bw-poly": "0.000000000000000 5.35356812179089e-4 4.99266072928606e-10 4.27370422037554e-12 -6.68245573791717e-16",
"cx": "1927.764404",
"cy": "1096.686646",
"height": "2168",
"width": "3848"
},
"protocol": "camera.gmsl"
}
],
"vehicle": {
"valid": false
}
},
"version": 6
}
In your (now deleted?) post you said
Below paramater used by our QA to test Valeo camera on link 0 with CSI-ab port. Could you please make changes accordingly and try?
"parameter": "camera-name=V1SIM728MPRU3030ND1,disable-custintf=1,disable-auth=1,interface=csi-ab,skip-eeprom=1,CPHY-mode=1,link=0,fifo-size=8,output-format=raw+processed,async-record=1,deserializer=MAX96724_Fusa_nv,file-buffer-size=16777216,format=mp4"
I tried to incorporate the differences in parameters from my setup suggested by that post and it still fails with a stack-smash.
So is there any parameter string that works with the Valeo IMX728 or Valeo IMX623 sensor which will not stack-smash?
I cannot reproduce what your QA team claims as a “it worked for us” test.
Not at this time.