BadPtr after several iterations

C++. Its may be more question of debugging in Visual Studio and working with memory.

I have a program that analyzes list of files, and path to current file is a concatenation of to strings: CString object named 'folder' and filename itself(CString too).

But after 144'th iteration(im sure the number is unimportant), folder suddenly turns into a BadPtr and application crashes with Access Violation. To check, i've created a CFileFind object with the same directory and instead of concatenating with folder i concatenate with finder.GetRoot(). Same story, 144th iteration and crash.

The question is, how can i protect the memory of this variable(its ok before 144th iteration) or trace the function which actually writes on that location or whatever else to debug this problem. During the cycle, folder variable is not changed at all. Actually its within the private section of some class and all functions appearing in the cycle have no acces to this private section.

Code goes like this(there can be some typos cuz i cut some unimportant things out of it):

typedef map<CString, list< CRect > > metadata;
...
metadata::iterator it=mt.begin();
list< CRect >::iterator it_l;
float i=0;

while(it!=mt.end()){
        if(cur.Load(folder+"\\"+(*it).first+".jpg")){
            it_l=(*it).second.begin();
            i+=1.0;
            while(it_l!=(*it).second.end()){
                cur.buildVector(*it_l);
                cur.printVector(mf,',');
                mf<<",1"<<"\n";
                it_l++;
            }
        }
        it++;
    }

buildVector collects features in CRect object of current image, cur.Load loads the image itsef, printVector prints vector to ofstream named mf. i counts iterations.

UPDATE: I examined my code, commented all the lines but cur.Load(...) and still had crash but on 584th iteration. Looks like its overwriting memory problem. I looked through all the functions in Load:

    bool Image::Load(CString& path){
     if(!src.IsNull()){ 
        src.Destroy();
     }
     src.Load(path);    
     width=src.GetWidth();
     height=src.GetHeight();
     fillBrightnessMatrix();
     fillGradientMatrices();
     return true;
    }

and discovered that commenting fillBrightnessMatrix() makes iterations go through the end of the list without any errors. This function is the only one that works with memory, and here go开发者_如何学运维es its code:

 void Image::fillBrightnessMatrix(){
    const int nPitch = src.GetPitch();

    const unsigned int nWidth = src.GetWidth();
    const unsigned int nHeight = src.GetHeight();
    BYTE * pxPixel = reinterpret_cast<BYTE*>(src.GetBits());


    for(int nY = 0; nY < nHeight; ++nY)
    { 
        for(int nX = 0; nX < nWidth; ++nX)
        {
            pxPixel += 3;
            bright[nX][nY]=((*pxPixel+*(pxPixel+1)+*(pxPixel+2))/3.0)/255.0;
        };

        if(nPitch >= 0)
            pxPixel += nPitch - (nWidth*3);
        else
            pxPixel -= ((nWidth*3) + (nPitch*(-1)));
    };
}

bright is allocated in constructor, its double[500][500]. Actually, i dont see any memory leaks in this code, what am i doing wrong?

Now debugger points to this line:

bright[nX][nY]=((*pxPixel+*(pxPixel+1)+*(pxPixel+2))/3.0)/255.0;

saying pxPixel is a BadPtr >.< damn i dont understand a thing.

I haven't looked at your code, but this smells like someone writing over the bounds of their data. To catch something like this:

• Let your loop run up to the 143rd iteration. (Use a conditional breakpoint to break at the 143rd time.) Examine your folder to make sure it really is still Ok.
• Set a data breakpoint on the address of its data. (I don't know CString, so I can't help you there.)
• Single-step through the code.
• When the data breakpoint hits, look at the stack to find out what's happening.