A possible approach when finding seg faults is: start program with gdb, run it, when segfault is hit then show backtrace. This allows to see where the problem occurred. When programs are build with debug, then source code line numbers are available.
When looking to the code, there is a frame grab and then an analysis with "1.7s to be predicted". I would not do these two tasks with threads, as the frame grab most possibly will be in milliseconds. Why not grab frame, then do analysis, grab next frame, do ... which avoids the lock problems.
The libraries for frame grab, cv and model most possibly do rely on external libraries/code. Try to run these parts step by step (and not in parallel) and see if seg faults still happen.
When looking to the code, there is a frame grab and then an analysis with "1.7s to be predicted". I would not do these two tasks with threads, as the frame grab most possibly will be in milliseconds. Why not grab frame, then do analysis, grab next frame, do ... which avoids the lock problems.
The libraries for frame grab, cv and model most possibly do rely on external libraries/code. Try to run these parts step by step (and not in parallel) and see if seg faults still happen.
Statistics: Posted by ghp — Wed Apr 17, 2024 4:10 am