ben2316's profile - activity

For using this in command line arguments in Visual Studio, see http://stackoverflow.com/questions/7882295/how-to-include-the-percent-character-in-the-visual-studio-debugger-command-line

Does anyone know if the OpenCV pre-built Windows libraries are compiled with TBB?

How about if I didn't compile OpenCV from source?

I just noticed that GridAdaptedFeatureDetector::detectImpl (in modules/features2d/src/detectors.cpp) uses cv::parallel_for_ in its implementation. I'm assuming that means that it uses multithreading to speed up the feature detection process. My question is: is there a way I can force this to run in serial? The motivation to turn off multithreading is to do performance testing, to see how my code runs faster or slower, serially, based on different code changes. Is there a compile flag or function call I need to do?

I think I solved my problem. In the code below, I kept reassigning the Mat variable image while looping through sub-directories of images.

Mat image;
for(directory_iterator di(dirPath); di != directory_iterator(); di++)
{
  // read in file
  if(is_directory(di->path()))
  {
    for(directory_iterator j(di->path()); j != directory_iterator(); j++)
    {
      image = imread(j->path().c_str(), CV_LOAD_IMAGE_COLOR);
   ...
      Mat maskImage = getMask(image);
   ...

When I declared image in the innermost for-loop, I stopped having problems. Can anyone explain why reassigning image multiple times would eventually cause memory problems?

forgot to mention that in some instances the error was "double free or corruption"

I'm reading in many images to do feature extraction and training for an SVM, and I keep getting seemingly random segmentation faults when the code reads in over X images and tries to release a Mat object from a function:

*** glibc detected *** /home/.../build/test: free(): invalid pointer: 0x0000000001bd3100 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7ffff65ceb96]
/home/.../build/test(_ZN2cv3Mat7releaseEv+0x4b)[0x40de29]
/home/.../build/test(_ZN2cv3MatD1Ev+0x18)[0x40dae2]
/home/.../build/test(_Z7getMaskN2cv3MatE+0x798)[0x40c568]
/home/.../build/test(main+0x510)[0x40d0bd]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ffff657176d]
/home/.../build/test[0x40bab9]

.....

(gdb) bt
0  0x00007ffff6586425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff6589b8b in __GI_abort () at abort.c:91
#2  0x00007ffff65c439e in __libc_message (do_abort=2, fmt=0x7ffff66ce008 "*** glibc detected *** %s: %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#3  0x00007ffff65ceb96 in malloc_printerr (action=3, str=0x7ffff66ca913 "free(): invalid pointer", ptr=<optimized out>)
at malloc.c:5018
#4  0x000000000040de29 in cv::Mat::release (this=0x7fffffffd420) at /usr/local/include/opencv2/core/mat.hpp:367
#5  0x000000000040dae2 in cv::Mat::~Mat (this=0x7fffffffd420, __in_chrg=<optimized out>)
at /usr/local/include/opencv2/core/mat.hpp:276
#6  0x000000000040c568 in getMask (input=...) at /home/.../test.cpp:109
#7  0x000000000040d0bd in main (argc=2, argv=0x7fffffffe258) at /home/.../test.cpp:195

test.cpp:109 is the last line of this code block (return finalMask):

Mat getMask(Mat input)
{
  ...
  Mat finalMask;
  const Size ksize(14,14);
  morphologyEx(realMask, finalMask, MORPH_CLOSE, getStructuringElement(MORPH_ELLIPSE, ksize));
  const double thresh = 255.0 / 2.0;
  const double maxval = 255.0;
  threshold(finalMask, finalMask, thresh, maxval, THRESH_BINARY);
  return finalMask;
}

I've been trying to narrow down the problem, but I can't seem to figure it out. In some examples, it fails on consistently on the 423rd image read in. Other times when I changed the code, it failed consistently on the 547th image. Can anyone point me in the right direction to debug this problem?