tags:

views:

80

answers:

4

Hi all,

i have a quite strange problem. my class has -among others- following memers:

GLboolean has_alpha; 
GLuint width;
GLuint height;
GLuint length;
GLuint millisPerFrame;
GLfloat uv[2];
GLuint texsize[2];
GLint compsize;
    // location2 
long preload_interval_next;
long preload_interval;

if i put the has_alpha at (location2) i get

a) different object size, sizeof reports 248 instead of 252 bytes

and

b) hefty heap corruptions

GLboolean is defined as unsigned char, but since i use NO optimization at all ( double checked this ) this should be padded to 4 bytes anyway. And in the end, if it pads, it should do it at both locations ..

compilers tested: CLANG ( c++ ), GCC4.2 com.apple.compilers.llvmgcc42

Anyone an idea how to track this down?

+2  A: 

I highly doubt the problem is in the code you posted. You'd need to show us the rest of the class. However some hints:

a) may happen due to alignment (no, it shouldn't do it at both places the same, read about data alignment)

b) may happen if you pass a pointer of this structure to some GL calls that expect some kind of ordered alignment

Kornel Kisielewicz
+1  A: 

If you want to find out where the padding occurs, you can use the -Wpadding option of gcc, or try out pahole, which can be used to optimize the structure size: https://twiki.cern.ch/twiki/bin/view/Atlas/UsingPahole

ergosys
+1  A: 

The problem here is almost certainly not in the members you have listed, but another one, possibly an int, pointer or bool that is not properly initialised in the constructor. Please post a larger example that fails, and make sure you initialise all members using the constructor initialisation list.

Alex Brown
The problem was indeed somewhere in the derived base classes
+1  A: 

If it's at the beginning it HAS to pad to have the other variables on the right alignment. If it's at the end it doesn't have to pad and it might be able to disappear into the already padded size. No mystery there.

Heap corruption is nothing to do with this, it's just being exposed by having different allocations due to the new size - that is, random chance.

Charles Eli Cheese
its not at the end, there are following members of long type