开发者

get heap corruption when changing member variables order

开发者 https://www.devze.com 2022-12-17 18:12 出处:网络
i have a quite strange problem. my class has -among others- following memers: GLboolean has_alpha; GLuint width;

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

GLboolean has_alpha; 
GLuint width;
GLuint height;
GLuint length;
GLuint millisPerF开发者_开发问答rame;
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?


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.


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


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


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消