this pointer

[wysota]

Sending a reference to an image across threads is what causes the problem. You have to send a const reference or a copy instead.

[freekill]

Sending a reference to an image across threads is what causes the problem. You have to send a const reference or a copy instead.

Whoa! This actually worked like magic! Just curious though, the program now runs however, when I use gdb I still get a segmentation fault.
0x7c96df51 in ntdll! RtlpNtMakeTemporaryKey ()
from C:\WINDOWS\system32\ntdll.dll

I googled for the error and it points out to be internal to Windows dlls. How could I have accessed such? And why still the error in gdb?

[high_flyer]

are you protecting your image with mutexes?

[freekill]

are you protecting your image with mutexes?

No. I'm actually capturing images real-time through a webcam. But I made it multithreaded. I have a dedicated thread querying the webcam for a new image (which should happen every 30ms for typical webcams). When querying is successful, I place the image in a buffer and I wake up the rendering thread. The rendering thread converts the OpenCV's IplImage format to Qt's QImage format then painting happens.

Based on the clockings I'm currently observing, the conversion process (IplImage to QImage) along with the painting, takes some time and I get to skip some images captured by the webcam. This is acceptable though, as long as the latest image in the buffer gets to be displayed on screen. My image buffer contains only the latest frame captured by the webcam instead of stacking up the images in a queue.

[high_flyer]

No

You really should!
Even if its not the only problem in your application, it is a major one!
You have to protect mutual exclusive data, otherwise you get situations in which two threads are accessing the same resource at the same time - and that is "not good"!

[freekill]

I see, thanks for the advice. But which data do you think I need to lock/unlock?
1. Write to image buffer? (Only a single thread is writing on to the buffer)
2. Read to the image buffer? (Might be, 2 threads are reading the same image in the buffer but I feel it's not an issue reading data at the same time)
3. Update of QPixmap data before painting? (I believe not the case, because even if I get to update it on and on, multiple calls to update() is fine.)

If in the case of 1 and 2, I ran into some trouble as I could not unlock the mutex after function return:

IplImage* ImageBuffer::getFrame()
{
    QReadLocker readLocker(&rwLock);
    return image; //rwLock fails to be unlocked on function return
}

IplImage* ImageBuffer::getFrame()
{
    QReadLocker readLocker(&rwLock);
    return image; //rwLock fails to be unlocked on function return
}

To copy to clipboard, switch view to plain text mode 

[boudie]

Maybe you should use 2 image buffers:
- Renderer locks buffer #1 to read and render; you capture to buffer #2.
- As soon as the renderer is ready it unlocks buffer #1 and the capture goes to buffer #1 while releasing buffer #2 to be rendered.

So at the start of every capture you check which buffer is safe to use.
The renderer has to wait until the other buffer is released. Only in that case there is a new image availbale, because an image can never be written to the just rendered buffer.

Let us know if it actually works...

[high_flyer]

But which data do you think I need to lock/unlock?

Any data which is accessed by more then one thread needs to be protected.

1. Write to image buffer? (Only a single thread is writing on to the buffer)

Yes, but if it is the SAME buffer that is being accessed by other threads, it has to be protected, even more so if you have references to this elements in other places (and you have).
Threaded programming can get very messy and very hard to debug if you don't understand the principals and traps associated with it.
You should really read some tutorials, and get to know threaded programming.
Its not trivial, and the way to think about it is different then non threaded programming.

[freekill]

Thanks high_flyer, I'll take those pointers.

@boudie
I'm very much open to your suggestion. Using two buffers could actually speed up data access as I could read and write simultaneously without worrying to much about having my buffer blocked. However, I'm also using the buffer for synchronization. My rendering thread goes to sleep whenever it is finished with its rendering. I wake up the thread when a new image has been placed in the buffer. I do this using a wait condition. I feel I could not implement my current idea of sleeping threads with this suggestion.