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

Answer 1

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.