GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
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;
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);
so no bug -> closed. But maybe the RGBA thing should be mentioned on http://www.openframeworks.cc/documentation/gl/ofFbo.html ?
hmm - isn't this still a bug?
I don't see why the pixels.clear() should cause a crash on GL_RGB.
You're right. I thought that the FBO always returns GL_RGBA. But according to this line https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrameworks/gl/ofFbo.cpp#L766 the set format should be considered and ofPixels should store correct data that can also be released properly.
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
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.
I'm going to set up a simple example on the weekend
Just as a note: Might be related to the code around it. But not the system. We tried it on two different computers.
So, @faebser did you ever get around to setting up that minimal example?
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 : https://gist.github.com/977bbeb1fc0d40688227. 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).
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.
no problem @faebser. also make sure to try admsyn's tests, so we can pinpoint the issue better.
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.
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 ;)
Woop! @bilderbuchi close time?
I think it is safe to close this...