c++ new crashing in release only (MSVS10)

Question

When running the release executable only (No problems occur when running through visual studio) my program crashes. When using "attach to process" function visual studio indicates the crash occurred in the following function:

World::blockmap World::newBlankBlockmap(int sideLen, int h){
    cout << "newBlankBlockmap side: "<<std::to_string((long long)sideLen) << endl;
    cout << "newBlankBlockmap height: "<<std::to_string((long long)h) << endl;
    short*** bm = new short**[sideLen];
    for(int i=0;i<sideLen;i++){
        bm[i] = new short*[h];
        for(int j=0;j<h;j++){
            bm[i][j] = new short[sideLen];
            for (int k = 0; k < sideLen ; k++)
            {
                bm[i][j][k] = blocks->getAIR_BLOCK();
            }
        }
    }
    return (blockmap)bm;
}

Which is called from a child class...

World::chunk* World_E::newChunkMap(World::floatmap north, World::floatmap east, World::floatmap south, World::floatmap west
,float lowlow, float highlow, float highhigh, float lowhigh, bool displaceSides){
    World::chunk* c = newChunk(World::CHUNK_SIZE+1,World::HEIGHT);

    for (int i = 0; i < World::CHUNK_SIZE ; i++)
    {
        for (int k = 0; k < World::CHUNK_SIZE ; k++)
        {
            c->bm[i][0][k] = blocks->getDUMMY_BLOCK();
        }
    }

    c->bm[(int)floor((float)(World::CHUNK_SIZE+1)/2.0f)-1][1][(int)floor((float)(World::CHUNK_SIZE+1)/2.0f)-1] = blocks->getSTONE_BLOCK();
    c->bm[(int)ceil((float)(World::CHUNK_SIZE+1)/2.0f)-1][1][(int)floor((float)(World::CHUNK_SIZE+1)/2.0f)-1] = blocks->getSTONE_BLOCK();
    c->bm[(int)floor((float)(World::CHUNK_SIZE+1)/2.0f)-1][1][(int)ceil((float)(World::CHUNK_SIZE+1)/2.0f)-1] = blocks->getSTONE_BLOCK();
    c->bm[(int)ceil((float)(World::CHUNK_SIZE+1)/2.0f)-1][1][(int)ceil((float)(World::CHUNK_SIZE+1)/2.0f)-1] = blocks->getSTONE_BLOCK();

    return c;

}

where...

class World {
public: typedef short*** blockmap;
...

The line which VS points at is...

short*** bm = new short**[sideLen];

The "attach to process" function stats the Local variables are... sideLen = 1911407648 h = 0 which is what i did NOT expect, but the cout outputs 9 and 30 respectively, which was expected.

I am aware that most "crashes in release only" problems are due to uninitialized variables, however, I fail to see that related here.

The only error message I get is... Windows has triggered a breakpoint in Blocks Project.exe. This may be due to a corruption of the heap

I am stumped on this problem, what's the error? how can I better debug release executable?

I can post more code if needed, however, bear in mind there is a lot of it.

Thank you in advanced.

"And I don't see World::newBlankBlockmap() called from that second chunk of code. – Michael Burr", I forgot that bit, here you go...

World::chunk* World::newChunk(int side, int height){
cout << "newChunk side: "<<std::to_string((long long)side) << endl;
cout << "newChunk height: "<<std::to_string((long long)height) << endl;
chunk* ch = new chunk();
ch->bm = newBlankBlockmap(side,height);
ch->fm = newBlankFloatmap(side);
return ch;

}

where...

struct chunk {
    blockmap bm;
    floatmap fm;
};

as defined in the World class

"The "attach to process" function states the Local variables are..." - you can't trust what the debugger says for local variable values in a release/optimized build. I'd guess that the variable values are fine (as written to `cout`), but something that happened before has corrupted the heap. — Michael Burr, Mar 03 '12 at 08:18
And I don't see `World::newBlankBlockmap()` called from that second chunk of code. — Michael Burr, Mar 03 '12 at 08:27
Why to you need to convert to `long long` and then to `string` to print the values? Just print what comes in, you never know... — nplatis, Mar 03 '12 at 08:32
Also in the second code block, the type conversions to `(float)` are not necessary: since one of the operands (in your case, the second one) is `float`, a full division is performed and the result is a floating point number. — nplatis, Mar 03 '12 at 08:50
this is a very nice example of what my guru would call, on a slightly sacrastic tone, 'highly refactorable code'. Refactor it, and the crash will be gone. — stijn, Mar 03 '12 at 09:20
`Three Star Programming` http://c2.com/cgi/wiki?ThreeStarProgrammer You might be misled by line at which VS stops, since release build optimizations might be reordering commands or otherwise mess thing up. What is the exception itself, is it access violation reading memory? writing memory? at which address? — Roman R., Mar 03 '12 at 09:24
Also, each time you manually manage multiple memory areas, writing exception safe code becomes highly non-trivial. One could also argue that every asterisk inreases the exponent in the code's complexity. — Sebastian Mach, Mar 03 '12 at 10:36
You might well do `short*** bm = new short[sideLen][h][sideLen];` — quantum, Mar 03 '12 at 18:32

score 2 · Accepted Answer · answered Mar 03 '12 at 10:18

To reiterate what the comments where hinting at: From what you've posted, you're code seems to be badly structured. Triple pointer constructs like short*** are almost impossible to debug and should be avoided at all costs. The heap corruption error message you got suggests that you have a bad memory access somewhere in your code, which is impossible to find automatically with your current setup.

Your only options at this point are to either dig through your entire code manually, until you've found the bug, or start refactoring. The latter might seem like the more time-consuming now, but it won't be if you plan to work with this code in the future.

Consider the following as possible hints for a refactoring:

Don't use plain arrays for storing values. std::vector is just as effective and a lot easier to debug.
Avoid plain new and delete. In modern C++ with the STL containers and smart pointers, plain memory allocation should only happen in very rare exceptional cases.
Always range-check your array access operations. If you worry about performance, use asserts which disappear in release builds, but be sure the checks are there when you need them for debugging.
Modeling three-dimensional arrays in C++ can be tricky, since operator[] only offers support for one-dimensional arrays. A nice compromise is using operator() instead, which can take an arbitrary number of indices.
Avoid C-style casts. They can be very unpredictable. Use the C++ casts static_cast, dynamic_castand reinterpret_cast instead. If you find yourself using reinterpret_cast regularly, you probably have a mistake in your design somewhere.

+1: and, of course, each time you manually managa multiple memory areas, making this exception safe is highly non-trivial — Sebastian Mach, Mar 03 '12 at 10:33

score 0 · Answer 2 · answered Mar 03 '12 at 10:14

There is a problem in this line short*** bm = new short**[sideLen];. The memory is allocated for sideLen elements, but the assignment line bm[i][j][k] = blocks->getAIR_BLOCK(); requires an array having size sideLen * sideLen * h. To fix this problem changing of the 1st line to short*** bm = new short**[sideLen * sideLen * h]; is required.

c++ new crashing in release only (MSVS10)

2 Answers2