3 cameras streaming with GstNvArgusCameraSrc - if one connection is faulty, the whole system shuts down!

[mechi.fendel]

Continuing the discussion from 3 cameras streaming with GstNvArgusCameraSrc - if one of the connections is faulty, the whole system shuts down!:

Yes this IS still an important issue.

(My email was changed, and that’s why the response i sent last week didn’t arrive correctly)

[linuxdev]

I did not read the whole discussion, and I am not really a camera guy, but SIGSEGV is usually easy to trace. Without debug symbols it might not be in as much detail, but are you running a particular program, and can you run that program on command line? If so, then you could run this in gdb, and get a stack dump (backtrace). Without debug symbols this would be limited, but it is a start (it might indicate getting the debug symbols for a package, or using strace or ltrace to look at failed system or library calls).

Let’s say the program is started with “gstreamer”. We’ll call any arguments in a chain “ARG”. A chain implies a single long argument parsed by gstreamer. This is different from several different arguments; in one case it is a single argument which is parsed by gstreamer after gstreamer sees it, while the opposite of discrete arguments are those which the command line itself parses. I only mention this because some of the camera commands are long chains of pipe setup, and are technically a single argument. I will assume this example, you will need to substitute with the actual program:
gdb gstreamer

This puts you in the debugger. Then you can enter arguments:

set args ARG0 ARG1

Then start running:
r

If it succeeds and the program ends, use “q” to quit. If there is an error, copy what you see. Then get a backtrace (stack dump):
bt

Without symbols not much will show up, but it is a start. At this point, knowing the program and arguments and a backtrace, there might be debug symbols as a separate package for that program (or if you build the software, it could be rebuilt with symbols).

Barring that helping, strace would be the next tool. Also, don’t forget to monitor “dmesg --follow” while doing this to see any new log lines.

Incidentally, if cameras require a certain amount of bandwidth, and there is too much for the USB to handle it, then I would expect a failure (not every camera is designed to fall back to a lower speed USB standard). However, to fail with a SIGSEGV would be “bad behavior” even if failure is expected. It should be handled more gracefully, but we don’t know if it is a problem in the program, in the USB, or in a library (at least not yet). Be sure to state the exact program and arguments.

Then

[JerryChang]

hello mechi.fendel,

let’s narrow down the issue, is this specific with gst pipeline?
could you please check with low-level test apps to enable multi-stream for testing,
(1) you may try argus_multi_camera.
it’s by default launching six camera for 100-frames, you may using cmd options to change output streams and frame counts.
for example, $ ./argus_multi_camera -n 4 -c 500

(2) or, you may launching argus_camera app with setting --module as ‘Multi Session’ mode, and specify the index to launch the argus_camera app.
here’s an example, $ ./argus_camera --module=3 --multidevices=1,2,3,4