Uninitialized memory blocks in VC++

Question

As everyone knows, the Visual C++ runtime marks uninitialized or just freed memory blocks with special non-zero markers. Is there any way to disable this behavior entirely w

Answer 1

Why not create your own #define and get in the habit of using it?

I.e.

#define SafeDelete(mem) { delete mem; mem = NULL; }
#define SafeDeleteArray(mem) { delete [] mem; mem = NULL; }

Obviously you can name it whatever you like. deleteZ, deletesafe, whatever you're comfortable with.

Answer 2

What's happening is my code crashes under a debug compilation, but succeeds under a release compilation.

Release build will crash on customer's machine. It always does.

I've checked it under a debugger and my pointers are getting set to 0xFEEEFEEE after I call delete on them.

Pointers are not changed after you call delete on them. It's the memory they point to that gets set to 0xfeeefeee, 0xfeeefeee, ..., 0xfeeefeee.

If you spot that your program reads data from freed memory (which is conveniently indicated by 0xfeeefeee pattern in DEBUG build), you have a bug.

Answer 3

@[Jeff Hubbard]:

What's happening is my code crashes under a debug compilation, but succeeds under a release compilation. I've checked it under a debugger and my pointers are getting set to 0xFEEEFEEE after I call delete on them. Again, same code on release doesn't crash and behaves as expected.

This is very strange behavior - I'm still convinced that there's probably a latent bug that's being hidden by the _CrtSetAllocHook() workaround.

The 0xFEEEFEEE signature is used by the OS heap manager to indicate freed memory (see http://www.nobugs.org/developer/win32/debug_crt_heap.html). By any chance can you post some repro code and indicate exactly which compiler version you're using?