Possible Errors with OpenGL and texture pointers

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

Quote: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:

Code:
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! Wink
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
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.
Quote this message in a reply
Member
Posts: 114
Joined: 2005.03
Post: #3
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
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.
Quote this message in a reply
Jones
Unregistered
 
Post: #5
OneSadCookie Wrote: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.

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

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:
Quote: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.
Quote this message in a reply
Jones
Unregistered
 
Post: #6
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. Rasp

[Image: 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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  OpenGL ES Texture Masking airfire 6 14,709 Mar 17, 2014 07:07 PM
Last Post: baioses
  OpenGL ES Texture Compression ajrs84 9 4,094 May 7, 2013 03:36 PM
Last Post: ajrs84
  OpenGL ES Texture Masking dalasjoe sin 0 3,833 Apr 13, 2012 12:17 AM
Last Post: dalasjoe sin
  Texture in OpenGL ES 2 looks pixelated vunterslaush 18 23,093 Aug 30, 2011 09:44 PM
Last Post: Frogblast
  Lighting and changing texture colors in OpenGL agreendev 2 7,672 Aug 13, 2010 03:47 PM
Last Post: agreendev