crash on ofPixels_<PixelType>::clear() #1533

faebser opened this Issue Sep 2, 2012 · 16 comments


None yet
7 participants

faebser commented Sep 2, 2012

I'm trying to read the color value from an ofFbo via ofPixels.
I'm using the dev-branch on of and i just pulled and recompiled OF.

ofPixels_<unsigned char> pixels;
ofColor testColor = pixels.getColor(x / mult, y / mult);

As soon as pixels.clear() gets called my application aborts with saying:
*** glibc detected *** ./planetsGame1: double free or corruption (!prev): 0x00000000031a1870 ***

my debugger says it's the following line (ofPixels.cpp, Line 328):

if(pixelsOwner) delete[] pixels;

faebser commented Sep 2, 2012

Quick correction: It is line 238 not 328.
And we, @underdoeg and me, found the problem:
When allocating the FBO I choose GL_RBG

testFbo.allocate(ofGetWidth()/2, ofGetHeight()/2, GL_RGB, 1);

by switching over to GL_RGBA the error disappears.

testFbo.allocate(ofGetWidth()/2, ofGetHeight()/2, GL_RGBA, 1);

underdoeg commented Sep 2, 2012

so no bug -> closed. But maybe the RGBA thing should be mentioned on ?

@underdoeg underdoeg closed this Sep 2, 2012


ofTheo commented Sep 2, 2012

hmm - isn't this still a bug?
I don't see why the pixels.clear() should cause a crash on GL_RGB.


underdoeg commented Sep 2, 2012

You're right. I thought that the FBO always returns GL_RGBA. But according to this line the set format should be considered and ofPixels should store correct data that can also be released properly.

@underdoeg underdoeg reopened this Sep 2, 2012


arturoc commented Sep 4, 2012

i'm testing this and not getting a crash with both GL_RGB or GL_RGBA. it actually doesn't make sense that it crashes in the delete no matter if the allocation was wrong, which from the code seems to be ok. if it was allocated with a different size it should crash when trying to read more pixels than allocated memory but when deleting it it shoul just work.

can you replicate the same crash in a simple example with only that code? it could be some kind of memory corruption from other part of your code


damian0815 commented Sep 5, 2012

the original error message was a 'double free or corruption' -- i think it's an assertion firing from a debug malloc rather than an actual crash due to badness.

faebser commented Sep 5, 2012

I'm going to set up a simple example on the weekend


underdoeg commented Sep 5, 2012

Just as a note: Might be related to the code around it. But not the system. We tried it on two different computers.


bilderbuchi commented Jan 12, 2013

So, @faebser did you ever get around to setting up that minimal example?


admsyn commented Jan 12, 2013

I haven't been able to replicate this issue either.

In the interest of getting this issue closed, I've put up a couple of simple tests here : They basically just try to run through the fbo creation, pixel read and pixel clear code in different contexts (only in setup, on / off stack, etc).

faebser commented Jan 14, 2013

I'm really sorry but in the wake of my bachelor thesis I totally lost track of this. I will dig up my code tonight after work and will update this accordingly.


bilderbuchi commented Jan 14, 2013

no problem @faebser. also make sure to try admsyn's tests, so we can pinpoint the issue better.

faebser commented Jan 15, 2013

I found the line in my old code but didn't yet got around seperating it out from the surrounding code. Will do that as soon as possible.

faebser commented Jan 28, 2013

After some working with both my code and @admsyn 's test I wasn't able to reproduce the mentioned bug outside of my code which leaves me no other conclusion than that i should clean up and rewrite my code. I think this issue can be closed and be labeld as DAU-related ;)


admsyn commented Jan 29, 2013

Woop! @bilderbuchi close time?


underdoeg commented Jan 29, 2013

I think it is safe to close this...

@underdoeg underdoeg closed this Jan 29, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment