Unique Ptr of threads quiting unexpectedly

I have a deque of threaded image loaders.

deque<unique_ptr<oneImage>> testQ;

every once and a while I pop one out and push another one in.

    testQ.pop_back();
    testQ.push_front(move(unique_ptr<oneImage>(new oneImage)));

This was working great, until I moved it over to from my mac to linux. It fails on pop_back(); The application just quits with no errors or information. Sometimes there is a pop up that says sigsegv. Whether the crash happens seems dependent on how many images I have loaded in the deque - it does not happen each time I pop_back() out.

This is a very time sensitive issue and I would really appreciate it if someone could give me some pointers ? Perhaps it has something to do with my swap space?

you probably need to stop the thread and wait on it before popping it back (which deletes it), otherwise the thread would keep running and might crash.

stopping and starting threads on runtime is never a good idea, it’s easier, faster and safer to create a pool of threads and use them whenever you need one.

also in general you want to have as max number of threads the number of cores in the machine, having more than that is not verty useful. then you can send tasks to this threads using for example ofThreadChannel

Thanks Arturo, I already tried stoping the thread and waiting for the thread to stop before popping it. It didn’t work. I’m switching it over to using a pool of threads rather than popping the thread themselves.

I am very curious why my reckless deque popping failed on linux, but worked on mac!

I was looking into how you you were using ofThreadChannel in OfxThreadedImageLoader, but I need to crop the images on the thread as well and I couldn’t quite wrap my head around how to do that with a ThreadChannel.

ofxTaskQueue https://github.com/bakercp/ofxTaskQueue handles some of the complexities of image loading and keeping making sure openGL things happen in the main thread.

It also allows you to set the maximum number of threads, get feedback etc.

1 Like

Race conditions, segmentation faults and similar errors won’t happen deterministically (or at least won’t look like) they depend on a lot of conditions even if the machine is for example faster it might make the error happen sooner. also in some platforms accessing opengl from a different thread won’t work but won’t crash while in others it’ll crash the application.

1 Like