Sign in to follow this  
relpats_eht

The strangest bug I have ever seen.

Recommended Posts

relpats_eht    138
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[i].textureFilename) > 0){
            ilGenImages(1, &texturePtr);
            ilBindImage(texturePtr);             
            if(!ilLoadImage(material[i].textureFilename)){
                ilBindImage(0);
            } 
            iluNegative();
            material[i].texture = ilutGLBindTexImage();                       
            ilDeleteImages(1, &texturePtr);
        }else{
            material[i].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[i].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[i].textureFilename)){
                ilBindImage(0);
            }
allegro_message("4.1.6: %d", numMaterials);  
            iluNegative();
allegro_message("4.1.7: %d", numMaterials); 
            material[i].texture = ilutGLBindTexImage();
allegro_message("4.1.8: %d", numMaterials);                         
            ilDeleteImages(1, &texturePtr);
allegro_message("4.1.9: %d", numMaterials); 
        }else{
            material[i].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]

Share this post


Link to post
Share on other sites
Enigma    1410
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 destructed

void bang()
{
int * ip = getDanglingPointer();
*ip = 6; // invalid pointer access
}

Enigma

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this