Is it possible to mark a segment of memory as “out of bounds” so the heap manager doesn't allocate from it?

Question

Earlier today I asked this question.

After spending some time investigating this issue, I have discovered what is going on. I am posting this as a new question because I think it is interesting enough to track as a separate issue. I will update that question with the answer (and a link to this one).

Launching unit test from debugger

// Construct object
Object* pObject = new Object(...);
// Pointer value of pObject == 0x05176960

// Lots of other code
// ...

// Destroy object
delete pObject;

// Construct object again
pObject = new Object(...);
// Pointer value of pObject == 0x05560194     /* Different memory location */

Launching unit test from command line

// Construct object
Object* pObject = new Object(...);
// Pointer value of pObject == 0x05176960

// Lots of other code
// ...

// Destroy object
delete pObject;

// Construct object again
pObject = new Object(...);
// Pointer value of pObject == 0x05176960     /* Same memory location */

In summary:

• When launching the unit test from the command line, subsequent calls to new to allocate an Object (deleteing the previous Object before allocating a new one) always return the same address in memory.
• When launching the unit test from the debugger, subsequent calls to new to allocate an Object (deleteing the previous Object before allocating a new one) always return a unique address in memory.

The problem is that because allocations of Object always get the same address in memory when launching through the command line, a map which I am accessing which has stored the old pointer can still be used and the test won't crash. But I want my unit test to crash when the defect fix is not in place, to ensure that it doesn't silently fail and the defect doesn't come back.

There are 2 parts to my question:

1. Why would the heap manager re-use the same part of memory when launching a unit test from the command line, but not when I launch the unit test from the debugger?

2. Is there a compiler setting I could use on my test harness, or a method I can call to prevent the heap manager from re-using a section of memory that I have deleted, to allow me to correctly write my unit test? ¹

---

¹Obviously one way of doing this is to not delete the original object, but the part of the code that allocates this is in my production code, and I doing this would result in memory leaks.

Answer 1

Your unit test is flawed, since it's relying on undefined behavior. You should rewrite your unit test so that it doesn't rely on undefined behavior, in which case it will always pass regardless of how the memory manager decides to allocate memory.

What you're doing is this:

Object* pObject = new Object(...);
...
delete pObject;
pObject = new Object(...);
// Use dangling pointer to first object, and if it crashes, the unit test fails
// This is WRONG since a crash isn't guaranteed

You should instead restructure the unit test so it works like this:

Object* pObject = new Object(...);
...
// Check to see if there are dangling references to pObject right before we
// delete it.  If there are, assert() and fail the unit test.
assert(NoDanglingReferences(pObject));
delete pObject;
// Continue on with more tests

Answer 2

You could replace new and delete with your own versions that have the behaviour you want.

Answer 3

First of all - not in a "normal" memory manager. Once you deallocate memory you pass ownership of it to the memory manager and the latter can reuse it.

You could write a custom manager as user Andreas Brinck suggests, but what would it do? It doesn't craft memory from air, it requests it from somewhere like CRT heap or operating system heap.

Scenario A. It wouldn't return memory to the underlying heap - you'll have a leak and the memory block will still be mapped into the address space and it will be accessible.

Scenario B. It will return memory to underlying heap - then when your mananger tries to allocate memory again the underlying heap can return that block again. Also you don't know what the underlying heap does when you return memory to it. It might make it unmapped or not - so accessing that memory might crash or not.

The bottom line is you're screwed. Trying to test undefined behavior is not going to be very productive.

Answer 4

This is an example of UNDEFINED BEHAVIOUR. Neither C++ or the heap manager define how memory is going to be allocated. You cannot rely on either memory being reused or not being reused. When you do something like in the above, there is no way to determine or change whether or not the pointer returned will be different from the first allocated.