Crash when creating a texture on a thread



I am loading images from disk on a thread and intermittently get a crash (in the same place every time). There does not seem to be a valid opengl context i think

Here is a screenshot of the crash

I cant seem to work out whats going wrong. Only thing that i am doing on the main thread while the images are loading is drawing a circle.

ci::gl::clear(ci::ColorAf(0.41f, 0.65f, 0.05f, 1.f));
ci::gl::drawSolidCircle(ci::app::getWindowCenter(), m_fRadius);


Have you checked the FlickrTestMultithreaded example?

There are also some threads in the forum about this, it might help


@xumo Hi there, i have read those forum posts. I am pretty sure its not the issue i am having. I am creating an opengl context in my worker thread. There is no communication between worker thread and main thread other than a promise/future. I don’t use the textures i load on the main thread until after the worker thread has exited.

This crash always happens when the worker thread is in the process of loading the last texture from a list of textures to load.


So, i think the problem is that my opengl context gets corrupted some how. Only thing i have started doing recently is using my own shaders as oppose to cinders gl::draw functions.

This does not happen all the time. Maybe 1 in 100 times i run in the app in visual studio

I thought a good way to catch it is to monitor the opengl context. Anyone know a good way to check the context status?


I would just create surface in your thread, which doesn’t require gl context, and you can convert surface to texture in the main thread. You might need an callback function which tells your main thread that your surface is loaded and then you convert it to the texture.


I think there is no need of a callback if you use a circularbuffer.
I would avoid to have a separate gl context just for loading textures if you need them in the main thread.
You can always use a pbo to upload the texture data asynchronously.


i am using a ci::ConcurrentCircularBuffer already. The solution i have has never had a problem before now so i think it has to do with writing and loading in my own shaders. I would rather work out what is happening than change to another solution just yet.

Thanks for the suggestions @dashandslash & @avseoul. I will look into the pbo solution.