App Crashing inconsistently when using Pixel::getColor() in thread


Hi All,

I’m using a thread to load a sequence of images one-by-one with timed delay and extract pixel color for use elsewhere in my app. I have 5 images (all 360x360 JPG files) in a source folder that I’m loading one by one at sixty second intervals.

The app runs through the loop multiple times, then unexpectedly crashes at unpredictable points.

The crash report shows:

Crashed Thread:        3

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000001198e0000
Exception Note:        EXC_CORPSE_NOTIFY

with the culprit being:

0 cc.openFrameworks.ofapp 0x000000010fba2726 ofPixels_<unsigned char>::Pixel::getColor() const + 502 1 cc.openFrameworks.ofapp 0x000000010fba2520 ofPixels_<unsigned char>::getColor(int, int) const + 128

as I mentioned, the images themselves don’t appear to be corrupted in any way, and each image loads several times before the crash eventually happens.

Anyone experienced anything like this before?



There are probably conflicts with the GL thread and your thread.
If you use setUseTexture( false ); in your setup, does that fix it?


I’m doing things similar… I run several threads that communicates with the main thread…

Basically I don’t load, play or do anything threaded related with the player (whatever it’s a videoplayer, an image, a computed texture, anything related with graphics)… The threads call methods on the mainApp to to change states, then within the update method I do use the state to load or play a media…

You can use several std::atomic<bool> or a std::atomic<int> state for communication between threads and and main thread.


Hi Nick,

Thanks for the response. I guess my previous description was slightly inaccurate. I’m actually passing a reference to an ofPixels object into a function, then using that reference to extract the color data, so from what I understand the setUseTexture(false) doesn’t apply in this context?:

ofColor extract(const ofPixels& pixelData)
const ofColor& myColor = pixelData.getColor(i, j);

Yes, that should be correct. Are you using lock(), unlock() when accessing variables that are present in both threads?


Hi Nick,

I’ve isolated the problem and it doesn’t seem to be the Thread that’s at fault. I’ve removed all the thread components and the crash now occurs during setup without the use of threading, I’ve moved the first call of the extract() method into setup for the very reason of isolating the error and now the app crash inconsistently on startup. It’s always the same line in the source code that’s the culprit:

 template<typename PixelType>
ofColor_<PixelType> ofPixels_<PixelType>::Pixel::getColor() const{
	ofColor_<PixelType> c;
			c.set( pixel[0], pixel[1], pixel[2] );
			c.set( pixel[2], pixel[1], pixel[0] );
			c.set( pixel[0], pixel[1], pixel[2], pixel[3] ); // <-------- CULPRIT
			c.set( pixel[2], pixel[1], pixel[0], pixel[3] );
			c.set( pixel[0] );
			c.set( pixel[0], pixel[0], pixel[0], pixel[1] );

presumably the error is caused by an empty/incorrect location in memory in the char * array? What I can’t seem to grasp is why there is no consistency and sometimes it crashes, sometimes it doesn’t. I tried generating a new oF project file, and it worked for a while without crashing, then went back to crash every 3/4 startup…


there might be a bug in the pixels iterators, can you post a small example that crashes and the line in your code that triggers the crash?


Hi. I face exactly the same problem. Crash occurs on call
particle.color = pix.getColor(particle.location.x, particle.location.y);

please see the screenshot.


This often happens when requesting a value of x / y that are out of bounds. Are you certain particle.location.x < pix.getWidth() and particle.location.y < pix.getHeight()?

1 Like

Thank you @bakercp. I do:

if ( particle.location.x < pix.getWidth() && particle.location.y < pix.getHeight()){
        particle.color = pix.getColor(particle.location.x, particle.location.y);

and my app doesn’t crash anymore. Thank you again.

1 Like