0

For some reason, this code produces an access violation at the second imread, but not the first. 

#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
using namespace cv;

int main(int argc, char **argv)
{
    Mat mat1, mat2;

    char imgname1[255]="cise_StackD.tif";
    mat1 = imread( imgname1, CV_LOAD_IMAGE_GRAYSCALE); 

    char imgname2[255]="ecise_StackD.tif";
    mat2 = imread( imgname2, CV_LOAD_IMAGE_GRAYSCALE); 

    return 0;
}

The exact runtime error message is: "Unhandled exception at 0x61f437ef (msvcr100d.dll) in MLMVNroThrust.exe: 0xC0000005: Access violation reading location 0xcccccccc." The identical code with identical visible project settings runs acceptably on another PC. The images are identical copies.

I'm using OpenCV 2.4.3 prebuilt binaries; the projects are set up to use CUDA as well, but I have stripped out all CUDA code in order to isolate the problem.

What makes this Access Violation and how do I get rid of it?

Thanks.

talonmies
  • 70,661
  • 34
  • 192
  • 269
jwilson75503
  • 57
  • 7
  • 1
    Is it actually the extra letter in the filename? If you swap the two calls to `imread`, is it then the first call that throws? Somehow that seems unlikely to me. – us2012 Jan 12 '13 at 04:33
  • Some other people on SO found that using Release libraries may help: http://stackoverflow.com/questions/8164932/unhandled-exception-on-opencvvs2010 – us2012 Jan 12 '13 at 04:36
  • Can you post the files somewhere so we can try? Eliminate the char array and stick the image name string directly in the function call. Are the files available? Trying using fopen to open the files just to see if they exist from the working directory in which you're running it. Visual studio has a nasty habit of using your source folder as the working directory, not where the actual exe file is. I've used this kind of code in debug no problem. – Gustavo Litovsky Jan 12 '13 at 06:04
  • @us2012 - Indeed, if I swap the call order, the first one throws. – jwilson75503 Jan 12 '13 at 21:55
  • @Gustavo Litovsky, using the image name directly still causes the violation. I made sure the image is there under both names, and the copy that loads can be displayed normally. But even with no image in the directory under either name, the behavior does not change. [image with full name is here](http://www.clueland.com/temp/Pepper_Y-Precise_StackD.tif) – jwilson75503 Jan 12 '13 at 22:03
  • Did you check the working path that the debugger is using? Manually go to the folder using command line and run the application from command line. If it works, then the file cannot find the file. – Gustavo Litovsky Jan 12 '13 at 22:44
  • @gustavo, I have run it from the folder where the exe is located, C:\ProgramData\NVIDIA Corporation\CUDA Samples\v5.0\bin\win32\Debug . With the above code, Win 7 reports the exe has stopped working. If I comment out the second imread, the exe runs with no problem, even with no image files to load. This is the correct behavior for imread, if it cannot read an image file it is expected to return a valid but empty Mat instead of raising an exception. – jwilson75503 Jan 12 '13 at 23:00
  • @us2012, setting my linker input settings to use OpenCV 2.4.3 release libs leads to a different exception. If I change the IDE from debug to Release, the exe works fine. – jwilson75503 Jan 12 '13 at 23:34

1 Answers1

0

Per this post on the OpenCV forums, this happens when using Visual C++ 2008 with an OpenCV path meant for 2010 (OPENCV_AV was set to "%OPENCV_ROOT%\x86\vc10").

I have corrected this problem on my lab PC (OPENCV_AV is now set to "%OPENCV_ROOT%\x86\vc9"), which was set up with Visual C++ 2010 for use by previous researchers.

Thanks to all who responded!

jwilson75503
  • 57
  • 7