Possible Errors with OpenGL and texture pointers

[Jones]

I've got code with problems. (Doesn't it always start this way?) A little bit into the data loading procedure I get this:

OpenGL(3223,0xa000ed98) malloc: *** vm_allocate(size=3592814592) failed (error code=3)
OpenGL(3223,0xa000ed98) malloc: *** error: can't allocate region
OpenGL(3223,0xa000ed98) malloc: *** set a breakpoint in szone_error to debug
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc

I think their are two possibilities here:

1) OpenGL has no more memory. Not likely.
2) I've screwed up by passing OpenGL funky pointers or something. Likely.

I'm gonna leave out a lot of code and give you the short version, which I hope will suffice for this situation.

Here's the basics:
a) I have a class with a GLuint, it's not a pointer.
b) The above GLuint is for 3D OpenGL textures.
c) I have a function, that is *not* part of said class. But is called from the class.
d) This function expects a pointer to a GLuint. (It needs to be a pointer to avoid the funky address of stuff, of course.
e) I pass an address of before-mentioned GLuint to said function.
f) The function passes it to glGenTextures and glBindTexture and glTexImage3D and gluBuild3DMipmaps, etc...

Here's the even short info:



GLuint myTex;

void foo(GLuint *target) {
glGenTextures(1, target);
glBindTexture(GL_TEXTURE_3D, target);
gluBuild3DMipmaps(... STUFF ...);
}

foo(&myTex);

// Is it in anyway likely or possible that this sucks?


I don't think it's because I'm giving OpenGL the incorrect OpenGL data, it seems more like an allocation problem of some sort.

Thanks for opinions/war stories/druken ramblings! ;)

[OneSadCookie]

Don't try to allocate 3.5GB of RAM, it won't generally work.

I'd guess an endian problem -- 3592814592 is 0xd6260000, which looks suspiciously like it should be 0x000026d6, which is 9942 -- a little under 10KB, much more sensible.

[Cochrane]

In glBindTexture you're using the pointer, but you should be using the value that your pointer points to. I don't know if this is the problem, though.

[OneSadCookie]

Also true... but the compiler should be screaming at you for that one. If it's not, you need to Crank up the warning settings (http://tips.onesadcookie.net/tips/published/GCC+Warning+Flags).

[Jones]

Also true... but the compiler should be screaming at you for that one. If it's not, you need to Crank up the warning settings (http://tips.onesadcookie.net/tips/published/GCC+Warning+Flags).

They are cranked up, according to the very warning flags you linked to. :p

The compiler doesn't give a hoot about the pointer stuff, it would seem. But then again, there's nothing wrong with that code, is there. It's more like an OpenGL incompatibility to the situation, correct?

As for the endian issue, that sounds like an excellent guess about what's going wrong. I'm gonna have to check the width/height/bpp values that FreeImage is giving me. If they're not swapped then there is certainly a problem. Or it might be one of my counters going way to high.

I will check them all with GDB.

EDIT: GDB seems to think that this line is the trouble causer:
tex_dat = (GLubyte*)new GLubyte[numberToUse * t1_width * t1_height * t1_components];


t1_width, t1_height are both 256.
t1_components is 3.
numberToUse is 3557218. Hmm. Not good.

I noticed that the program also thinks that the images it counted while building the final texture was the same as the size of each texture. But my code makes it *impossible* for this to happen. In this case the images counted should be 0 or 1. Number to use should also be 1. Not only that, but my arrays for counting and such are filled with random garbage numbers ranging from the millions in the negatives to the millions in the positives.

*strokes invisible beard* Strange... very strange.

[Jones]

Is it possible that because I've asked 'new' to allocate 3.5 gigs that other values in memory are getting messed with? That's the only answer I've got for some of my outrageously out-of-range values.

Thanks!

EDIT: Sorta fixed it. The errors were due to the fact that the memory being allocation was not zeroed, and contained previous big values. Must remember to loop through all my memory zeroing it next time. :p

http://homepage.mac.com/gareth.cross/stuff/almost_working.png

That my friends is a screenie of the almost working terrain code. How is it not working? Well, you'll note that it's only using one of several textures it *should*be using. Not as pretty this way.

[OneSadCookie]

If you want zeroed memory, you should use calloc().

And no, passing the pointer to glBindTexture is *not* correct. It probably won't crash, but only due to quirks of OpenGL. It's also potentially broken on 64-bit platforms.

If your compiler is not complaining about that line, then you need to investigate why not, before it causes you more grief. Certainly if it's not complaining, you *don't* have the warning flags set correctly.