ofxCv, openCV + threading?

advanced
#1

Can OfxCv/openCv be used within a thread or thread channel?
I found this post which is a bit old which seems to say yes, but no…(!)
http://answers.opencv.org/question/32415/thread-safe/

Background:
I’ve been using the threadChannel example to process images sent from ofxOMXPlayer,
and this seems to work really well, for simple CPU pixel manipulations.

I’ve also tried ofxCv inside the threadChannel example to do some simple face track, and contour finding. This seems to work well, but sometimes ( after 1 minute or several hours) I get a segmentation fault and my app
quits.

I’m using ofxCv, OF 0.9.8 + Jessie on a Raspberry PI 3.

TIA.

#2

your question is too generic, opencv per se is not thread safe or unsafe it depends on what you are doing and how you use it. In general though if you are not moving things in memory while accessing them in another thread it should be safe.

the best way to figure out this issues is to let the app run under the debugger and check the stack trace when it crashes.

#3

Thanks Arturo,

I’m compiling on PI from the command line - is there a specific way to do this so I get a decent stack trace?

#4

you can use gdb, just run:

gdb bin/projectName

then press r to start running. when it crashes type bt to get a stacktrace

#5

Thanks! have tried a few things but can’t seem to get gdb running. I’m used to Xcode so not too familiar with command line gdb.

Eventually got it to run after spending ages getting a compile with debug symbols, which were missing.
But it won’t work.

I get this error:

Starting program: /home/pi/openFrameworks/apps/myApps/threader01/bin/threader01_debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/arm-linux-gnueabihf/libthread_db.so.1”.
[New Thread 0x72f61200 (LWP 825)]
Cannot access memory at address 0x0

Program received signal SIGILL, Illegal instruction.
Cannot access memory at address 0x0
0x76b01de8 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0

so another afternoon of no progress… :frowning:

TIA

#6

Eventually found that you have to put: handle SIGILL nostop

into gdb to run…