0

I have following code somewhere in my application:

struct StreamFrame
    {
        cv::Mat imageDataRGB;
        cv::Mat imageDataBGR;
        FILETIME currentTime;
        std::vector<int8_t> metaData;
        int32_t dataLength;
    };

StreamData::StreamFrame StreamData::GetMetaData()
{
    mtx.lock();
    if (!sfQueue.empty())
    {
        single = sfQueue.front();  // the line causing the error
        sfQueue.pop();
    }
    mtx.unlock();

    return single;
}

For some reason I keep getting a deque iterator not dereferencable error, but my queue is a) not empty (18 elements in it when the error occurs), and b) threading should not be an issue since everything is locked via mutex.

What can I do to debug this? Note, this code has passed a million times already, and suddently it fails, and I have absolutely zip idea why this might happen.

Edit:

Definition of streamframe:

std::queue<StreamFrame> sfQueue;

Receiving a streamframe:

void StreamData::ReceiveFrame(StreamFrame* input, bool init)
{
    StreamFrame oneSF;
    oneSF.imageDataRGB = input->imageDataRGB.clone();
    oneSF.imageDataBGR = input->imageDataBGR.clone();
    oneSF.currentFrameTime = input->currentFrameTime;
    oneSF.metaData = input->metaData;
    oneSF.metaDataLength = input->metaDataLength;

    mtx.lock();
    sfQueue.push(oneSF);
    mtx.unlock();
}
SinisterMJ
  • 3,425
  • 2
  • 33
  • 53
  • "everything is locked via mutex" - since it fails in an "impossible" way after a huge number of iterations it sure smells like a race. Please show the enqueueing code too, the real definition of sfQueue, and anything else that's accessing it – Tom Goodfellow Dec 01 '16 at 09:25
  • Updated with the definition and the push to queue – SinisterMJ Dec 01 '16 at 09:46
  • 1
    So is the recently added locking in `GetMetaData` actually in the original code that spawned this question, or not? Unrelated, is there a reason for not using `std::lock_guard` (as opposed to manually locking+unlocking)? – WhozCraig Dec 01 '16 at 09:58
  • I added it, after noticing it wasn't there, but, it is still happening. – SinisterMJ Dec 01 '16 at 10:42
  • Note to self: copy the proper DLLs before testing. So far it seems to be working, appears as if the missing mutex around the push() caused this. – SinisterMJ Dec 01 '16 at 10:49
  • Question: why does the push (at the end of the queue) cause the front() to fail? They are accessing very different memory sections – SinisterMJ Dec 01 '16 at 10:55
  • Your sfQueue is based upon a std::deque, with mildly complex internals [as discussed here](http://stackoverflow.com/questions/6292332/what-really-is-a-deque-in-stl#6292437). Now imagine interleaving statement execution of push_back() and pop_front() and the only remaining surprise is that it failed so politely, rather than segfaulting. – Tom Goodfellow Dec 01 '16 at 11:40

0 Answers0