Hey All,
My program crashes violently when I perform a delete [] command on an existing array. Originally, it only crashed when completely detached from a debugger (using Visual Studio 2010 btw). At that point I googled and found a bunch of recommendations for application verifier. I downloaded that but found that when I attached it, the program no longer crashed and then verifier reported no errors...
However, after fiddling a bit more in Vs2010, I got my program to crash in release mode with the debugger attached. I thought I was clever when printing where the array pointer I am deleting points to, as I thought it would get overwritten and thus cause a crash when being deleted.
No such luck... I'm pretty confused right now. The array is a size of 1, never changes address, or at least - not from it's created all the way up to when it's deleted, and yet delete [] still causes an access violation...
Anyone have any ideas of what might help me pinpoint the problem?
Regards,
Gazoo
Heap Corruption ahoy
Presumably it was created with new[], rather than new, or malloc. And you aren't mixing runtimes? Do you have any linker warnings?
Have you tried using a std::vector<> instead, at least temporarily? The stronger type-checking involved with a class vs a pointer might help to catch a mistake elsewhere.
Have you tried using a std::vector<> instead, at least temporarily? The stronger type-checking involved with a class vs a pointer might help to catch a mistake elsewhere.
Make sure you aren't deleting it twice. Also, make sure you aren't overrunning the array bounds anywhere, because that can cause all manner of chaos.
As suggested, don't use raw arrays in the first place. They're prone to precisely this kind of nasty mistake, and basically are almost never justified in C++.
As suggested, don't use raw arrays in the first place. They're prone to precisely this kind of nasty mistake, and basically are almost never justified in C++.
Author
Heyo!
Thank you for the replies. I'm using an external library, so unfortunately I cannot rely on an std::vector. But I have done some good by moving a large portion of the memory allocation from the heap to the stack by turning things into references instead of using pointers.
My crashing still seems to wander back and forth between code segments. However, right now it seems to occur a lot when the stringstream object is automatically brought out of scope. I read a bit around on the net and found one of the most common problems is returning objects that immediately go out of scope, like
BUT! All of my calls to the aforementioned double function happen when calling another function that takes a cstring. My question is, shouldn't the objects still be in scope at that point? Lookey code example here:
Is that bad? Do I still need to allocate memory on the heap for the final cstring and copy it there while the function runs?
Gazoo
Thank you for the replies. I'm using an external library, so unfortunately I cannot rely on an std::vector. But I have done some good by moving a large portion of the memory allocation from the heap to the stack by turning things into references instead of using pointers.
My crashing still seems to wander back and forth between code segments. However, right now it seems to occur a lot when the stringstream object is automatically brought out of scope. I read a bit around on the net and found one of the most common problems is returning objects that immediately go out of scope, like
return myStringstream.str().c_str()
BUT! All of my calls to the aforementioned double function happen when calling another function that takes a cstring. My question is, shouldn't the objects still be in scope at that point? Lookey code example here:
std::stringstream myStringstream;
afunc(myStringstream.str().c_str());
Is that bad? Do I still need to allocate memory on the heap for the final cstring and copy it there while the function runs?
Gazoo
I'm using an external library, so unfortunately I cannot rely on an std::vector.
[/quote]
Are you sure? You can usually pass std::vector instances to external libraries by using &v.front(), v.size() (for the common case where the API expects a pointer to T and a length).
My program crashes violently when I perform a delete [] command on an existing array.Can you post some code describing this? How is the array created in the first place? Are you using DLLs at all?
But I have done some good by moving a large portion of the memory allocation from the heap to the stack by turning things into references instead of using pointers.[/quote]This sounds a bit suss, because you can use both references and pointers to refer to both stack and heap allocated objects...Is that bad? Do I still need to allocate memory on the heap for the final cstring and copy it there while the function runs?[/quote]No that should be fine, assuming that the function does not copy the input pointer into a member variable, or keep hold of it in some other way.
You should enable memory heap debugging to see if you're writing past the end of an array or double-deleting memory:
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF|_CRTDBG_CHECK_ALWAYS_DF);
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
