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

Closed
faebser opened this Issue Sep 2, 2012 · 16 comments

Comments

Projects
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;
testFbo.readToPixels(pixels);
ofColor testColor = pixels.getColor(x / mult, y / mult);
pixels.clear();

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);
Contributor

underdoeg commented Sep 2, 2012

so no bug -> closed. But maybe the RGBA thing should be mentioned on http://www.openframeworks.cc/documentation/gl/ofFbo.html ?

@underdoeg underdoeg closed this Sep 2, 2012

Contributor

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.

Contributor

underdoeg commented Sep 2, 2012

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.

@underdoeg underdoeg reopened this Sep 2, 2012

Owner

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

Contributor

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

Contributor

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.

Owner

bilderbuchi commented Jan 12, 2013

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

Member

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 : 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).

faebser commented Jan 14, 2013

Hi,
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.

Owner

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 ;)

Member

admsyn commented Jan 29, 2013

Woop! @bilderbuchi close time?

Contributor

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