Corrupt stack driving me up a wall for several days!

Hi, I'm using the DevIL image library to load an image for OpenGL. I've created a class to load textures simply by running a single function. and for some reason, whenever I run this code:

Code:

ilConvertImage(IL_RGBA,IL_UNSIGNED_BYTE); width = (unsigned int)ilGetInteger(IL_IMAGE_WIDTH ); height = (unsigned int)ilGetInteger(IL_IMAGE_HEIGHT); data = new unsigned char [200]; ilCopyPixels(0,0,0,width,height,1,IL_RGBA,IL_UNSIGNED_BYTE,data); GiveTextureToOpengl(); delete data; data = NULL;

It gives me a huge amount of exceptions after the 'new' statement (SIGSEV). The backtrace is huge, and involves a corrupt stack so I'm not sure it will help. The class is declared like so:

Code:

//!------------------------ class TextureRGBA { private: //internal functions int GiveTextureToOpengl(); void GenerateErrorBitmap(); public: GLubyte * data; uint width; uint height; GLuint handle; //load function bool load(char * filename); //activate function void SetCurrent(); void activate(); //constructors TextureRGBA(char * filename); TextureRGBA(); ~TextureRGBA(); }; //!------------------------

The whole function is:

Code:

bool TextureRGBA::load(char * filename) { ILuint names; ilGenImages(1,&names); ilBindImage(names); ilLoadImage(filename); if (ilGetError()!=IL_NO_ERROR) { GenerateErrorBitmap(); } else { ilConvertImage(IL_RGBA,IL_UNSIGNED_BYTE); width = (unsigned int)ilGetInteger(IL_IMAGE_WIDTH ); height = (unsigned int)ilGetInteger(IL_IMAGE_HEIGHT); data = new unsigned char [200]; ilCopyPixels(0,0,0,width,height,1,IL_RGBA,IL_UNSIGNED_BYTE,data); GiveTextureToOpengl(); delete data; data = NULL; } return true; 1; }

The stupid debugger, instead of giving me a reason of what is going on, gives me this:

Quote:

Program received signal SIGSEGV, Segmentation fault.
In Normaliz!IdnToUnicode () (K:\Projects\gameengine\devil.dll)

I'm using Mingw32, the latest version, with GDB 6.3, and a SVN version of Code::Blocks.

What I'm primarily wondering, is if it is my problem, or it is something with the library. This has been tearing my mind a new one for the past few days, and I've finally swallowed my pride and posted my problem here ;). I'm going to be straight up and honest, and say that I honestly have no clue as to why this is happening, or if it IS a corrupt stack, which by the way I have no idea what it is or what causes it :P. If it's the library, then could I simply go and use a new one instead. If its my problem, then how would I figure out what went wrong.

BTW, in case it helps, heres the disassembly to the function:

Quote:

0x401966 push %ebp
0x401967 mov %esp,%ebp
0x401969 push %ebx
0x40196a sub $0x34,%esp
0x40196d lea 0xfffffff8(%ebp),%eax
0x401970 mov %eax,0x4(%esp)
0x401974 movl $0x1,(%esp)
0x40197b mov 0x415288,%eax
0x401980 call *%eax
0x401982 mov 0xfffffff8(%ebp),%eax
0x401985 mov %eax,(%esp)
0x401988 mov 0x41527c,%eax
0x40198d call *%eax
0x40198f mov 0xc(%ebp),%eax
0x401992 mov %eax,(%esp)
0x401995 mov 0x415298,%eax
0x40199a call *%eax
0x40199c mov 0x41528c,%eax
0x4019a1 call *%eax
0x4019a3 test %eax,%eax
0x4019a5 je 0x4019b7 <TextureRGBA::load(char*)+81>
0x4019a7 mov 0x8(%ebp),%eax
0x4019aa mov %eax,(%esp)
0x4019ad call 0x4018b0 <TextureRGBA::GenerateErrorBitmap()>
0x4019b2 jmp 0x401a7a <TextureRGBA::load(char*)+276>
0x4019b7 movl $0x1401,0x4(%esp)
0x4019bf movl $0x1908,(%esp)
0x4019c6 mov 0x415280,%eax
0x4019cb call *%eax
0x4019cd mov 0x8(%ebp),%ebx
0x4019d0 movl $0xde4,(%esp)
0x4019d7 mov 0x415290,%eax
0x4019dc call *%eax
0x4019de mov %eax,0x4(%ebx)
0x4019e1 mov 0x8(%ebp),%ebx
0x4019e4 movl $0xde5,(%esp)
0x4019eb mov 0x415290,%eax
0x4019f0 call *%eax
0x4019f2 mov %eax,0x8(%ebx)
0x4019f5 mov 0x8(%ebp),%ebx
0x4019f8 movl $0xc8,(%esp)
0x4019ff call 0x402850 <operator new[](unsigned int)>
0x401a04 mov %eax,(%ebx)
0x401a06 mov 0x8(%ebp),%eax
0x401a09 mov (%eax),%eax
0x401a0b mov %eax,0x20(%esp)
0x401a0f movl $0x1401,0x1c(%esp)
0x401a17 movl $0x1908,0x18(%esp)
0x401a1f movl $0x1,0x14(%esp)
0x401a27 mov 0x8(%ebp),%eax
0x401a2a mov 0x8(%eax),%eax
0x401a2d mov %eax,0x10(%esp)
0x401a31 mov 0x8(%ebp),%eax
0x401a34 mov 0x4(%eax),%eax
0x401a37 mov %eax,0xc(%esp)
0x401a3b movl $0x0,0x8(%esp)
0x401a43 movl $0x0,0x4(%esp)
0x401a4b movl $0x0,(%esp)
0x401a52 mov 0x415284,%eax
0x401a57 call *%eax
0x401a59 mov 0x8(%ebp),%eax
0x401a5c mov %eax,(%esp)
0x401a5f call 0x4017ae <TextureRGBA::GiveTextureToOpengl()>
0x401a64 mov 0x8(%ebp),%eax
0x401a67 mov (%eax),%eax
0x401a69 mov %eax,(%esp)
0x401a6c call 0x4028f0 <operator delete(void*)>
0x401a71 mov 0x8(%ebp),%eax
0x401a74 movl $0x0,(%eax)
0x401a7a mov $0x1,%eax
0x401a7f add $0x34,%esp
0x401a82 pop %ebx
0x401a83 pop %ebp
0x401a84 ret

Any help at all would be extremely thankful.

What are the values of IL_IMAGE_WIDTH and IL_IMAGE_HEIGHT, which get assigned to width and height?

> data = new unsigned char [200];
So how does 200 relate to the variable width and height and the size of a single RGBA ?

> delete data;
You used new[ ], so you must do delete [ ] data;

Like Salem, I suspect this:

Code:

ilCopyPixels(0,0,0,width,height,1,IL_RGBA,IL_UNSIGNED_BYTE,data);

would possibly generate more than 200 bytes of data - from what I can tell, the image only needs to be more than 50 pixels [e.g. 25 x 2, 10 x 5 or some such] to overflow the bufferm since IL_RGBA is 4 bytes per pixel.

And of course, using the correct delete [] function should be corrected too.

--
Mats

First, I'd like to thank you guys for helping me. I really appreciate your time.

ilCopyPixels does not create data, but just assigns it. Just to clear that up.

(unsigned int)ilGetInteger(IL_IMAGE_WIDTH );

and

(unsigned int)ilGetInteger(IL_IMAGE_HEIGHT);

gets the currently binded image width and height, respectively (the library uses image names like opengl).

data = new unsigned char [200];

still creates an error even if I change it to width*height*4. How I got 200 there was from when I was error checking it to see if it was a problem with the library, and I removed the ilCopyPixels and ilGetInteger's by commenting them out. It still gave me an exception, and the backtrace led into "ntdll", although it might have been caused by me screwing up the new statment (of all things :D ), although I don't know how.

So its probablly a combonation of the new statement being out of syntax and the leftover number that mixing together, probablly messed me up. I'll try to fix it and see if it runs, but first I gotta get home from skoolz. Amazing how the littlest things can screw up your code:P.