C++ : How can I solve a first-chance exception caused at an unknown point?

Question

A C++ project I'm working on terminates upon throwing a first-chance exception. This occurs in Visual Studio 2008 in Debug mode when I first try to access a map<pair<int,int>, int> which contains a single key-value pair. There is nothing logically wrong with the code.

I've read up on first-chance exceptions and understand they may not always be problematic. Nonetheless I tried breaking at all such exceptions, and as expected found several are generated which cause no issue.

The class I'm working on is very large and contains many custom memory allocations. I surmise that somehow one of these is causing the problem. However I've spent several hours attempting to find a way to identify what's going wrong, and have been unable to do so.

The first-chance exception output is listed below. It isn't very helpful!

First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x762cd09c in theapp.exe: 0xC0000005: Access violation reading location 0x6c696d00.
First-chance exception at 0x0050ae33 in theapp.exe: 0xC0000005: Access violation reading location 0x00000010.
Unhandled exception at 0x0050ae33 in theapp.exe: 0xC0000005: Access violation reading location 0x00000010.

I'm really struggling at this point, and am unsure how to proceed.

Can anyone suggest how I might tackle this problem, and identify exactly what's going wrong? I'd be very grateful for your advice.

UPDATE

Here's the related code. The debugger breaks on the first cout statement listed in the nested FOR:

        // Inside operator() :

        map<pair<int,int>,int> resultIdByStructIds;
        pair<int,int> spair (-1,-1); // Structure pair ids reusable reference.

        int nextMapEntryId = 0;
        int nextNumCandidates = 0;
        // For each remaining candidate.
        for (int ci = 0; ci < numCandidates; ) {
            // If candidate has been mapped or found not viable this mapping round,
            // move past it.
            if (candidatesDoneThisRound[ci] == currentMappingRoundId) {
                ++ci;
                continue;
            }

            Candidate candidate = candidates[ci];
            const int tId = candidate.tVertexId;
            const int pId = candidate.pVertexId;

            // Grab the result for this structure pair.
            // Create it if it doesn't exist.
            // Avoid copying as slight optimisation; simply
            // store pointer to true result instead.
            spair.first = tInfos[tId].structure->id;
            spair.second = pInfos[pId].structure->id;

            // DEBUG
            cout << "resultIdByStructIds size: " << resultIdByStructIds.size() << endl;
            for (map<pair<int,int>,int>::const_iterator ids_id = resultIdByStructIds.begin(); ids_id != resultIdByStructIds.end(); ++ids_id) {
                cout << ids_id->first.first << endl; // * Debugger breaks here.
                cout << ids_id->first.second << endl;
                cout << ids_id->second << endl;
                printf("Structures(%i,%i) => %i\n",ids_id->first.first,ids_id->first.second,ids_id->second);
            }
            //

            // code continues...

UPDATE 2

Here's an image of the mouseover description for the map in question; it appears corrupted as Michael Burr suggested.

Answer 1

In general, to pinpoint the spot of code where the app crashes, you can turn on exception handling under Debug/Exceptions. In this case, you would expand the last branch and check Access Violation. Of course that will stop on all the access violations, and not just the bad one (accessing 0x10). You can minimize this by turning on the trap at the last known moment.

Typically you will discover some memory usage error. The easiest way to determine the cause of this type of error is a third party tool like BoundChecker which will yell at you as soon as you corrupt the memory. Lacking that, Raymond Chen's advice is spot on. Figure out what object is wrong, and use the watch window to see when it changed. Or more efficiently, use the Data Breakpoint feature to have the program stop when the data at a particular address changes.