Ask Your Question

Problem with FarnebackOpticalFlow / DeviceInfo

asked 2012-08-01 09:43:04 -0600

yann gravatar image

I'm having a problem with the cv::gp::FarnebackOpticalFlow class.

I built OpenCV 2.4.2 with CUDA support on a 32bit Windows machine. Everything works fine, my old projects as well as the sample program "farneback_optical_flow_gpu.exe" (that was built together with OpenCV2.4.2).

But, so far, I haven't managed to successfuly include FarnebackOpticalFlow in one of my own projects.

I can compile the code, but the programm always stops due to a write acess violation once it reaches the constructor (the line cv::gpu::FarnebackOpticalFlow d_calc;):

"Exception at 0x760ed36f, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) in cudart32_42_9!_cudaMutexOperation"

The source of the problem seems to be this function (gpumat.cpp, line 296 ff.):

void cv::gpu::DeviceInfo::query()
    cudaDeviceProp prop;
    cudaSafeCall(cudaGetDeviceProperties(&prop, device_id_));
    name_ =;
    multi_processor_count_ = prop.multiProcessorCount;
    majorVersion_ = prop.major;
    minorVersion_ = prop.minor;

But cudaGetDeviceProperties(&prop, device_id_) on its own works just fine (and returns the right values) when I include it somewhere else.

I tried building my own version of "farneback_optical_flow_gpu.exe" using the original code and encountered the problem described above (with both Microsoft Visual C++ 2010 Express and QT Creator).

I'm pretty sure that the code itself isn't the problem, the working .exe and my version include the same libraries from the same places (DependencyWalker), and were build by the same compiler.

What am I missing?

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2013-02-18 11:21:00 -0600

I've had a very closely related problem (crash in DeviceInfo query, only in release). I narrowed it down to the DeviceInfo structure itself, and it's use of std::string for storing name_. There seemed to be conflict between the way my application laid out the std::string internal members and the way the opencv dll did it, but I don't have a definite answer. What I did to fix it is go into the opencv source, make 'name_' a char[256] (same as cudaDeviceProps), change the string assignment to a strcpy and just cast to std::string in the getter (so not to break the interface). Seems fine now.

edit flag offensive delete link more

Question Tools


Asked: 2012-08-01 09:43:04 -0600

Seen: 843 times

Last updated: Feb 18 '13