hello casperlyngesen.mogensen,
would you please narrow down the issue, you may exclude opencv for testing,
for example, can you reproduce the same by simply running gst pipeline to launch camera preview frames?
Sure, would you like logs from Argus?
It can take hours to hit the seg fault, but will get back, when it happens again
yes, please share Argus daemon log, and also kernel logs for reference.
Hi
I actually had my fault from earlier today in the systemd logs, attached the log from nvargus-daemon. I do not have the kernel log from that time, but the only relevant entry I see, is this:
[11536.474315] [RCE] ERROR: camera-ip/vi5/vi5.c:745 [vi5_handle_eof] “General error queue is out of sync with frame queue. ts=11558435347200 sof_ts=11558435754816 gerror_code=2 gerror_data=a2 notify_bits=0”
Will try to recreate without OpenCv, but do not know when that will happen
argus.log (58.2 KB)
BTW,
how often did you see segmentation fault, what’s the failure rate?
it’s tested locally with the steps as mentioned in comment #28, I don’t see such errors from my side.
It happens after the camera has been re-initialised some times. If you wrap that command in a while true on the command-line, that mimics how I run it.
while [ true ]; do gst-launch-1.0 nvarguscamerasrc sensor-id=6 ! 'video/x-raw(memory:NVMM),framerate=30/1,format=NV12' ! nvvidconv ! xvimagesink; done
I had a crash again this night after some hours
argus.log (10.6 KB)
hello casperlyngesen.mogensen,
according to the logs, there’s timeout and software stack handling this error.
it needs 5 seconds (or more) for internal process to recover the state.
may I know what’s the exactly failure?
for example,
is there an intermittent signaling on sensor side?
or… you’ve disconnect/connect the camera device physically?
let me double confirm what’s happening after segmentation fault.
(1) are you able to interrupt the process to re-run the gst pipeline?
(2) is it possible to recover by restarting Argus daemon?
$ sudo pkill nvargus-daemon
$ sudo systemctl start nvargus-daemon
Hi
Yes, i can recover just fine. Do not need to restart nvargus-daemon, just need to restart my application
And it is intermittent signaling. Camera disconnect fails completely with Python and OpenCV (Not argus related)
hello casperlyngesen.mogensen,
thanks for clarification, it looks error handling mechanism is working as expected.
Yes, i agree. It is only the segmentation fault, that causes problems now
let me have clarification,
since there’s intermittent signaling, it shows timeout failures from camera pipeline. Argus will report it via EVENT_TYPE_ERROR, and the application has to shutdown.
the segmentation fault is expected to force-stop the application, due to you’ve also confirm the camera functionality after restart the application, the Argus error handling mechanism is functional.
Hi JerryChang. Would it be possible to provide patched versions of libnvscf.so and libnvargus.so for JP5.0.2 and JP5.1.0?
We have been suffering from the lack of error handling on this specific error also, but our systems in the field are based on both JP5.0.2 and JP5.1.0. This is affecting us in a big way.
While we will upgrade eventually, we cannot do it immediately. Thank you.
So the segfault is expected? So if we switch to libargus directly, we can get events and handle the errors proberly?
hi all,
sorry, we don’t back porting the fixes to previous release.
you may moving to JP-5.1.1 to apply the pre-built update, or waiting for next public Jetpack release.
it’s expected failure from user-space side to terminate the application.
the error handling mechanism is implemented in software stack, it also works with libargus.
I will give libargus a try, but yesterday we had a lot of seg faults from nvargus-daemon.
If we have three cameras running and one fails with nvargus-daemon doing the segmentation fault, the other two will hang until we restart the application. The last part might be a problem in the gstreamer pipeline, so let’s see what libargus can do for us
hello casperlyngesen.mogensen,
since there’s pre-built update to address the stability issue,
let’s submit a new thread for following-up your use-case. you may leave the topic-id here for better tracking.
I will do that, when i have done some testing without gstreamer and opencv.
I also started testing the new libnvargus.so and libnvscf.so and immediately ran into a crash after a timeout. It is 100% reproducible simply by disabling streaming using:
echo 0 | sudo tee /sys/kernel/debug/camera-video0/streaming
while capture is running. The original argus did not crash. I posted the crash dump at:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.