How to identify array overflows?

[Robert Pope]

After the last coding addition to my program, it started crashing periodically. I've able to track it down to my direction array (int travDir[239]). Something wrote over the first ten elements. But how can I figure out what is writing out of bounds? It doesn't crash when the overwrite happens, but later when I try to read what got written over.

I'm using Visual Studio C++ Express, but programming in straight C.

[Ron Murawski]

Try using some of the standard tools like Splint and DUMA, or a new one called Dr Memory.

Splint: http://www.splint.org/
DUMA: http://duma.sourceforge.net/
Dr Memory: http://code.google.com/p/drmemory/

Ron

[trojanfoe]

After the last coding addition to my program, it started crashing periodically. I've able to track it down to my direction array (int travDir[239]). Something wrote over the first ten elements. But how can I figure out what is writing out of bounds? It doesn't crash when the overwrite happens, but later when I try to read what got written over.

I'm using Visual Studio C++ Express, but programming in straight C.

Don't expose your arrays or vectors from the class and instead implement bounds-checking accessor methods; for example:

Code: Select all

class MyClass {
protected:
    std::vector<int> m_nums;

public:
    void setNum(size_t index, int num) {
        assert(index < m_nums.size());
        m_nums[index] = num;
    }
};

This will still cause a crash, however it will be explicit. At the end of the day if you are using the wrong indexes then the code is broken and only you can fix it.

[Sven]

After the last coding addition to my program, it started crashing periodically. I've able to track it down to my direction array (int travDir[239]). Something wrote over the first ten elements. But how can I figure out what is writing out of bounds? It doesn't crash when the overwrite happens, but later when I try to read what got written over.

I'm using Visual Studio C++ Express, but programming in straight C.

Don't expose your arrays or vectors from the class and instead implement bounds-checking accessor methods; for example:

Code: Select all

class MyClass {
protected:
    std::vector<int> m_nums;

public:
    void setNum(size_t index, int num) {
        assert(index < m_nums.size());
        m_nums[index] = num;
    }
};

This will still cause a crash, however it will be explicit. At the end of the day if you are using the wrong indexes then the code is broken and only you can fix it.

Robert wrote he is using plain C ...

@Robert: To achieve the same as Andy wrote above you need to write a couple of accessor functions (inline if possible) where array bounds (not of travDir[] but of other arrays, maybe of those defined "close" to travDir[]) are checked with an assert(). But that is not always sufficient, sometimes memory corruption occurs indirectly via stack corruption, or via using a free'd memory block to which some entity still holds a pointer. Sometimes it can even happen through corruption of other data structures, like a struct that holds an array index and gets overwritten somehow. What I do to catch this type of error is to add a "safety zone" around my struct, e.g. 8 or 16 bytes initialized to zero at the beginning and at the end of the real data. Then I write a check function with an assert() that the "safety zone" bytes are still zero, and call it at appropriate places (e.g. at beginning and end of each makeMove(), each node entered, each generateMoves() etc.).

Another way to catch the bug (albeit sometimes a very slow one) may be to set a memory breakpoint in Visual Studio.

I would also check which data are located directly before your travDir[] array in memory, maybe you already find the problem that way.

Good luck!

Sven

[Robert Pope]

Try using some of the standard tools like Splint and DUMA, or a new one called Dr Memory.

Splint: http://www.splint.org/
DUMA: http://duma.sourceforge.net/
Dr Memory: http://code.google.com/p/drmemory/

Ron

Thanks, I'll take a look at those.

I managed to manually track down this particular issue: I was testing a simple one-ply check extension. Normally, that would be naturally self-limiting. But I already had a "Don't enter Quies() at depth 0 when in check" code that extended in a different spot.

So the edge case of giving perpetual check at depth 0 gave an infinite number two-ply extensions, which blew up the index for my killer move array.

[Ron Murawski]

Try using some of the standard tools like Splint and DUMA, or a new one called Dr Memory.

Splint: http://www.splint.org/
DUMA: http://duma.sourceforge.net/
Dr Memory: http://code.google.com/p/drmemory/

Ron

Thanks, I'll take a look at those.

I managed to manually track down this particular issue: I was testing a simple one-ply check extension. Normally, that would be naturally self-limiting. But I already had a "Don't enter Quies() at depth 0 when in check" code that extended in a different spot.

So the edge case of giving perpetual check at depth 0 gave an infinite number two-ply extensions, which blew up the index for my killer move array.

I'm glad you found your bug. Remember to program defensively and add as many sanity checks as you can think of in a debug version of your engine.

Ron

[rreagan]

Remember to program defensively and add as many sanity checks as you can think of in a debug version of your engine.

Yes, this can't be said enough. Protect those invariants! Spend a few minutes today. Those minutes will save you days or weeks later on.