delete[] problem with release config...

I have a problem with trying to "delete[]" a pointer. I use MSVC++, and I know that we can call without any problem (normally) "delete[]" on a pointer that isn't being allocated to something, example:

Code:

---

int* a = 0;
delete[] a;
a = new int[100];

---

Though that worked, until today, when I changed my application's settings to "release", (instead of "debug") so it would get more optimized... But then it doesn't work anymore. Is this possible that "delete[]" on "release" configuration will not check for if the variable was already assigned to something? Is this possible that a "#define" for configuration might check in that delete function what is the configuration? Or am I unlucky?

Could you post the smallest and simplest compilable (or what you think should be compilable) code that demonstrates the error? Stating which version of MSVC used may also be useful for testing.

>Is this possible that "delete[]" on "release" configuration
No, in all configurations, delete[] is required to do nothing if given a null pointer. The only possible way this could happen, aside from a compiler bug, is if the global operator delete[] is replaced with a function that fails to perform this check. I would wager that your problem is somewhere else and only causes trouble at that point in your code.

Well, it seem that I figured out something else in the meanwhile, but for MSVC version, I have MSCV++ .NET... Well, so my piece of code comes from a class I was building, that looks something like this:

Code:

---


class Image {
        private:
                UINT        Width,
                                Height,
                                *Pixels;
        public:
                Image() {
                        Pixels = 0;
                }
                void Load_Image(string File_Name)
                {
                        ifstream        File;
                        File.open(File_Name.c_str(), std::ios::in | std::ios::binary);
                        File.read((char*)&Width, 4);
                        File.read((char*)&Height, 4);
                        delete[] Pixels;
                        Pixels = new UINT[Width * Height];
                        //all sort of other things...
                }
};

---

Note that I have only placed the beggining of the loading function, not to worry with all my other lines. So what I'm doing is a kind of image class, to load image in a file that I create myself, just for learning purposes... So I placed a "delete[]" where it should be when you would need to load a second image, just deleting in the same time the previous one stored in memory. Altough that some people would prefer placing the delete in another class's method, I just wanted to leave it there...

So this works to what I have concluded if the project is done in "debug" options, or under "release", if and only if the constructor is called AND if the class is used with a pointer. To all other tries I made, I get a "user breakpoint error at the "delete" line...

Quote:

---

I would wager that your problem is somewhere else and only causes trouble at that point in your code.

---

Saddly, I know that this is too much often true, but in those cases the error takes soo much time to find out. (At least for me, though...)

>in those cases the error takes soo much time to find out. (At least for me, though...)
For all of us. Memory bugs that don't show up until well after the corruption are among the most painful. Sometimes all you can do is watch the pointer and step through your program.

It is strange indeed. Are you sure you aren't deleting the pointer somewhere else?

EDIT: The class destructor will do that for you. But I reckon that is not what is happening, is it? I mean, you are calling Load_Image() repeatedly on the same instance.

I'm pretty sure that MSVC++6 crashed when deleting a NULL pointer. Maybe .Net 2002 (the first .Net) still exhibits the same behaviour?

You're going to have to paste a compilable and complete program which demonstrates the problem (try and make it as small as possible if you want people to actually look).

Whilst the problem shows up here, it is almost certain that the problem is down to mis-use of any prior allocated block, and without seeing the whole thing which crashes, there's no way to tell which one it might be.

Start by examinining all your new calls to check the sizes are correct.

Also, in a debug build, use crtdbg.h to assist with finding typical things which go wrong
- using uninitialised data
- use before alloc
- use after free
- double free
- freeing what wasn't allocated
- writing past the end of the buffer
http://www.amanjit-gill.de/articles/vc6_debug.html
http://msdn.microsoft.com/library/de...ngFeatures.asp