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
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 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:
This puts you in the debugger. Then you can enter arguments:
set args ARG0 ARG1
Then start running:
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):
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.