damned-me
commented
3 months ago I wanted to add some information and so I did a quick debug run with gdb (using the following command: /usr/bin/camera-streamer --http-port=8081 --camera-type=v4l2 --camera-path=/dev/video0 --camera-format=YUYV --camera-width=1280 --camera-height=720 --camera-fps=15 --camera-nbufs=4 --http-listen=0.0.0.0) and found this stack trace:
(gdb) b http_500
Breakpoint 1 at 0x37960: file util/http/http_methods.c, line 75.
(gdb) c
Continuing.
util/http/http.c: HTTP8081/0: Client connected 192.168.1.187 (fd=4).
util/http/http.c: HTTP8081/0: Request 'GET' '/stream' ''
[Switching to Thread 0xae639ac0 (LWP 3298)]
Thread 2 "camera-streamer" hit Breakpoint 1, http_500 (stream=0xa7c005f8, data=0x0) at util/http/http_methods.c:75
75 util/http/http_methods.c: No such file or directory.
(gdb) backtrace
#0 http_500 (stream=0xa7c005f8, data=0x0) at util/http/http_methods.c:75
#1 0x0002e380 in http_stream (worker=0x2fb380, stream=0xa7c005f8) at output/http_jpeg.c:96
#2 0x0003718c in http_process (worker=0x2fb380, stream=0xa7c005f8) at util/http/http.c:194
#3 0x0003732c in http_client (worker=0x2fb380) at util/http/http.c:221
#4 0x00037428 in http_worker (worker=0x2fb380) at util/http/http.c:243
#5 0xb6f84310 in start_thread (arg=0xae639ac0) at pthread_create.c:477
#6 0xb4e7b5c8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)meaning that the function buffer_lock_write_loop at http_jpeg.c:93 returns 0
I noted, breaking on buffer_lock.c:141, that the function can hit goto error with frames set to zero, which means that if the function fails to get the lock it exit with a return value equal to 0. Thus hitting the if(n == 0) in http_jpeg.c:91.
(gdb) c
Continuing.
util/http/http.c: HTTP8081/1: Client disconnected 192.168.1.10.
util/http/http.c: HTTP8081/0: Client connected 192.168.1.187 (fd=4).
util/http/http.c: HTTP8081/0: Request 'GET' '/stream' ''
[Switching to Thread 0xae639ac0 (LWP 3919)]
Thread 2 "camera-streamer" hit Breakpoint 5, buffer_lock_write_loop (buf_lock=0x2b3350 <stream_lock>, nframes=0, timeout_ms=0,
fn=0x2e24c <http_stream_buf_part>, data=0xa7c005f8) at device/buffer_lock.c:141
141 in device/buffer_lock.c
(gdb) backtrace
#0 buffer_lock_write_loop (buf_lock=0x2b3350 <stream_lock>, nframes=0, timeout_ms=0, fn=0x2e24c <http_stream_buf_part>, data=0xa7c005f8)
at device/buffer_lock.c:141
#1 0x0002e364 in http_stream (worker=0x2fb380, stream=0xa7c005f8) at output/http_jpeg.c:93
#2 0x0003718c in http_process (worker=0x2fb380, stream=0xa7c005f8) at util/http/http.c:194
#3 0x0003732c in http_client (worker=0x2fb380) at util/http/http.c:221
#4 0x00037428 in http_worker (worker=0x2fb380) at util/http/http.c:243
#5 0xb6f84310 in start_thread (arg=0xae639ac0) at pthread_create.c:477
#6 0xb4e7b5c8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) i locals
buf = 0x0
ret = -1259606884
counter = 0
frames = 0
deadline_ms = 4943263440
frame_stop_ms = 4941263443
(gdb)I wonder if this could be a concurrency related issue.
I'm using
camera-streameronoctopito expose two webcams connected to a RPI4. Both webcams work correctly on other devices.When connecting to the served ports with a
GET /stream, I often get a500status code, as in the following response.The service is up and running. A request to
/demonstrates that the server correctly exposes the resource:Note that the
systemdprocess reports no errors when trying to connectFollows the output of
journalctl -u camera-streamer\*that includes the run reported in the aforementioned output, also attaching a more comprehensive version of logs here.This configuration used to work at alternate intervals, sometimes the cameras would work correctly but suddently stops, without a clear reason or the occurring of a particular event. Currently, restarting the unit or rebooting the system won't fix the issue.
Some fixes I've already tried are:
systemctl restart camera-streamer,sudo camera-streamer-control restart, etc...)journalctl -fu camera-streamer\*looking for errors or warningssudo shutdown now -rI'm opening this issue after a post on the octoprint forum, more information can be found there. I may be switching to the "old" camera stack proposed by the octoprint mainline but, even if I didn't debug the program directly, I would be happy to provide valuable information for the resolution of the problem.
Thanks