ofImage.loadImage in ofThread

advanced
#1

I wrote a small video feed that loads images from a web url as fast as it can. The high level code is something like this:

void VideoFeedImageUrl::threadedFunction()
{
    while (isThreadRunning())
    {
        if (loader->loadImage(url)){
            lock();
            pixels = loader->getPixelsRef();
            unlock();
            ofSleepMillis(10);
        }
    }
}

I had errors before so I turned loader—which is an ofImage—into a pointer, so I could control destruction:

class VideoFeedImageUrl : public VideoFeed
{
public:
    ~VideoFeedImageUrl() { waitForThread(true); delete loader;}
    void threadedFunction() ;
    ofImage* loader;
};

However, when quitting oF, I still keep getting a nasty EXC_BAD_ACCESS on the following line:

#235:   FREE_IMAGE_FORMAT fif = FreeImage_GetFileTypeFromMemory(hmem);

Inside:

I would think that the destructor takes care of first waiting for the thread to join, then destroying the actual ofImage; ensuring that the rug isn’t pulled out from under the threaded function? I did this explicitly using a pointer and delete in the destructor. Does anybody have an idea what’s going wrong?

#2

the problem i think is that Freeimage has been closed but your thread is still trying to load images. try to stop the thread before the destruction of static objects begin. for example in the exit event in ofApp::exit() or listening for ofEvents().exit

#3

Thank you so much! I fixed the problem using your suggestion!

void ofApp::onExit()
{
    myVideoFeedPointer.reset(); // clear the ofPtr, calling the destructor.
}

But it is odd, no? I don’t know who manages FreeImage, but shouldn’t it be closed after all of the ofApp's member destructors (and thus, ~VideoFeedImageUrl() ) have completed? That way, we can just rely on automatic destruction, and we can assume that FreeImage is available as long as the app runs.

#4

the problem is that you can’t control the order in which objects are destroyed, it depends on the compiler, the order in which files are compiled… so there’s no way to ensure that everything is destroyed before doing something. the only way to avoid it is to not close freeimage at all which might be a posible solution since we only close it when the applciation ends