1

I have this short C++ program which takes snapshot images from a camera in a loop and displays them:

void GenericPGRTest::execute()
{
    // connect camera
    Camera *cam = Camera::Connect();

    // query resolution and create view window
    const Resolution res = cam->GetResolution();
    cv::namedWindow("View");

    c = 0;
    // keep taking snapshots until escape hit
    while (c != 27)
    {
        const uchar *buf = cam->SnapshotMono();
        // create image from buffer and display it
        cv::Mat image(res.height, res.width, CV_8UC1, (void*)buf);
        cv::imshow("Camera", image);
        c = cv::waitKey(1000);
    }
}

This uses a class (Camera) for camera control I created using the Point Grey SDK and functions from the OpenCV library to display the images. I'm not necessarily looking for answers relating to the usage of either of these libraries, but rather some insight on how to debug a bizarre problem in general. The problem is that the application freezes (not crashes) on the cam->SnapshotMono() line. Of course, I ran through the function with a debugger. Here is the contents:

const uchar* Camera::SnapshotMono()
{
    cam_.StartCapture();
    // get a frame
    Image image;
    cam_.RetrieveBuffer(&image);
    cam_.StopCapture();

    grey_buffer_.DeepCopy(&image);
    return grey_buffer_.GetData();
}

Now, every time I step through the function in the debugger, everything works OK. But the first time I do a "step over" instead of "step into" SnapshotMono(), bam, the program freezes. When I pause it at that time, I notice that it's stuck inside SnapshotMono() at the RetrieveBuffer() line. I know it's a blocking call so it theoretically can freeze (no idea why but it's possible), but why does it block when running normally and not when being debugged? This is one of the weirdest kinds of behaviour under debugging I've seen so far. Any idea why this could happen?

For those familiar with FlyCapture, the code above doesn't break as is, but rather only when I use StartCapture() in callback mode, then terminate it with StopCapture() before it.

Compiled with MSVC2010, OpenCV 2.4.5 and PGR FlyCapture 2.4R10.

neuviemeporte
  • 6,310
  • 10
  • 49
  • 78

1 Answers1

2

Wild guess ... but may it be that StartCapture already starts the process that ends up with having the buffer in ìmage, and if you step you leave it some time until you get to RetrieveBuffer. That's not the case if you run it all at once ...

schroder
  • 181
  • 1
  • 3
  • That is a possibility, which makes me wonder: when stepping through code, are all other threads frozen, or do they run normally? StartCapture() starts a new thread which is responsible for gathering frames in the background. If it's running normally while I'm slowly stepping through the code, it might have a lot more time to fill the buffer... – neuviemeporte Aug 29 '13 at 21:40
  • Seems like you were right; putting a Sleep(1000) call before RetrieveBuffer() makes it work. Strangely, Sleep(100) still makes it freeze. Now I just have to figure out why it freezes at all. :) – neuviemeporte Aug 29 '13 at 22:34
  • Knowing nothing about the API: Are you sure one is allowed to call RetrieveBuffer() directly after calling StartCapture() ? Is there no synchronization-is-capture-ready-can-i-talk-to-you() ? Also: Debuggers to black magic to thread synchronization so a blocking thread does not block the debugger itself. That's why you can step through and pause the code with he debugger but experience a deadlock without – user2722968 Aug 30 '13 at 06:14
  • @user2722968: to my knowledge there isn't. That would seem to be substantiated by the fact that Sleep(1000) makes it work. Looks like some timing issue. – neuviemeporte Aug 30 '13 at 09:10