Even though this is off topic for this list, here's what's happening. What you are seeing is a standard feature of the CRT on Windows. When you are debugging, the CRT will set the pointer to that particular pattern (0xfeeefeee) to signify that the memory has been deleted even if you set the pointer to 0. This is done to find the exact bug you had, i.e. a multiple delete. When you are running normally, you delete the pointer and then zero it out. Calling delete on a null pointer is technically safe so under a normal run, the second delete succeeded.
-Matt On Wed, Dec 29, 2010 at 12:22 AM, Paul Wellner Bou <[email protected]> wrote: > Good morning, > > thanks for your reply, Danny. Yes, true, I was dodging the bullet. Or > something even more tricky like dodging the bullet I shot in my feet. > First I was scared, how can this happen, different results when running > and debugging. But after finding the bug and figuring out what I did and > what is done behind it, its not so strange any more. > >> To fix the problem, you should zero-out the pointer after deleting the >> thing it points to avoid a dangling pointer (or use a RAII smart pointer). > > This was not fixing anything. I set them to zero, all of them. To fix it > I should just stop to delete an object twice. > >> But again there really are few reasons to be using old style arrays in >> C++ these days. Even if you're using an older API, std vector provides >> access to it's contents. > > I have my reasons. All these data will be passed to OpenGL. But that's > not the problem anyway. > > Thanks and regards > Paul. > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt-creator > _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-creator
