Heap corruption

[sipickles]

Hi,

I have a problem using bullet 2.75 in my own app, MSVC2005 winXP SP3. I have heap corruptions detected by MSVC when I do allocations of bullet objects. The debugger is pointing at:

static void *btAllocDefault(size_t size)
{
return malloc(size);
}

This occurs when I create new btAxisSweep3, or if I comment out my world creation, I get the same event in new btCompoundShape.

Firstly since bullet uses its own custom allocator, will it play nicely with things like Application verifier?

Since the demos all run fine, what can be the difference between my app and the demos? Is it because the bullet classes use a custom memory allocator but mine don't?

Thanks

simon

[mp-nico]

The fun thing about heap corruptions is that they will not neccessarily cause problems in the code section responsible for the heap corruption.

For example, we had a heap corruption a few month ago that caused the software to crash after random amounts of time. The crash occured always somewhere in the material system when deleting some temporary object.

We spent about 2 weeks only to find out that the heap corruption was caused by a completly unrelated code section that is using a STL priority queue. Someone ( who still is very sorry ) thought it was a good idea to adjust the priorities on objects that are still in the queue.

To his excuse, no one of us suspected that this will result in a heap corruption.

The moral of the story is: You never know what caused the heap corruption by looking at the code line that crashed. It will happend somewhere, sometime when the heap is altered.

--

You probably created the heap corruption some where in your own code.
If you are using C++ and STL, you can google for known STL quirks that are known to cause heap corruptions and double-check your code. Thats how we did it.