Advertisement

The strangest bug I have ever seen.

Started by July 18, 2005 03:01 PM
3 comments, last by kburkhart84 19 years, 1 month ago
Ok, I'm going to post this bug, though I doubt its fixibale, as it seems to break the very laws of electronic components. heres the problem, if i do this (numMaterials is 1)
void MSmodel::loadTextures(){
    int i;
    ILuint texturePtr;
        
    for(i=0; i<numMaterials; i++){
allegro_message("4.1.2: %d", numMaterials); 
        if(strlen(material.textureFilename) > 0){
            ilGenImages(1, &texturePtr);
            ilBindImage(texturePtr);             
            if(!ilLoadImage(material.textureFilename)){
                ilBindImage(0);
            } 
            iluNegative();
            material.texture = ilutGLBindTexImage();                       
            ilDeleteImages(1, &texturePtr);
        }else{
            material.texture = 0;
        }
    } 
}

i will get a message box saying "4.1.2: 1", as i should, and then one saying "4.1.2: 684", which means that numMaterials was being changed somewhere in that loop the first time it went though. Now I could accept that as a memory bug in one of the above function, but it gets much stranger. if i do this to try and find which function has the memory error that is changing the value of numMaterials
void MSmodel::loadTextures(){
    int i;
    ILuint texturePtr;
        
    for(i=0; i<numMaterials; i++){
allegro_message("4.1.2: %d", numMaterials); 
        if(strlen(material.textureFilename) > 0){
allegro_message("4.1.3: %d", numMaterials); 
            ilGenImages(1, &texturePtr);
allegro_message("4.1.4: %d", numMaterials); 
            ilBindImage(texturePtr);
allegro_message("4.1.5: %d", numMaterials);              
            if(!ilLoadImage(material.textureFilename)){
                ilBindImage(0);
            }
allegro_message("4.1.6: %d", numMaterials);  
            iluNegative();
allegro_message("4.1.7: %d", numMaterials); 
            material.texture = ilutGLBindTexImage();
allegro_message("4.1.8: %d", numMaterials);                         
            ilDeleteImages(1, &texturePtr);
allegro_message("4.1.9: %d", numMaterials); 
        }else{
            material.texture = 0;
        }
allegro_message("4.1.10: %d", numMaterials); 
    } 
allegro_message("4.1.11: %d", numMaterials); 
}

all the messages will say numMaterials is 1, and it does not change to 684. and in the second case, after the final message, when the function should return to wherever it had been called, it crashes. This bug has me completly lost. If anyone can help me on this, I will be greatly appreciative. [Edited by - relpats_eht on July 18, 2005 3:17:14 PM]
- relpats_eht
It's hardly an unusual bug. You're clobbering the heap or stack somewhere with a bad pointer access or overrunning the bounds of an array. In the first version the value that gets clobbered is numMaterials, but in the second version the additional program instructions and/or string table entries move things around in your program enough that either numMaterials is in a slightly different location in memory or your invalid access clobbers a slightly different area of memory.

I see you're using C-style null-terminated character arrays for text. These are a very common source of invalid accesses. Since you're using C++ you really should be using std::string, which is much safer and has little or no performance hit (it can even be faster than raw character arrays). Also check all your array accesses. If you're using std::vector or std::deque for your arrays (you really should be) then you can replace calls to operator[]() with calls to at() to get bounds-checked array access.

Finally, check all your pointer use. Make sure pointers are initialised before use and always point to valid objects. In particular look out for dangling pointers, where a pointer continues to be used even after the object it points to has been destructed:
int * getDanglingPointer(){	int i = 7;	return &i} // i is destructedvoid bang(){	int * ip = getDanglingPointer();	*ip = 6; // invalid pointer access}

Enigma
Advertisement
DevIL caused me a lot of heap corruption too :/
yeah, i got rid of devil and wrote my own image library.

of course it doesnt support as many formats, but it enough.
- relpats_eht
I only need BMP and TGA for auto transparency(alpha channel), that is all. I have my texture library that supports both. No need of Devil or anything else for that matter.


This topic is closed to new replies.

Advertisement