Sign in to follow this  
beebs1

Unable to delete?

Recommended Posts

Hiya,

Anyone have any ideas why this would fail?

[code]
wchar_t *filename = new wchar_t[filenameHeader->Length];
memcpy(filename, &mftBuffer[filenameOffset], filenameHeader->Length * sizeof(wchar_t));
filename[filenameHeader->Length] = L'\0';

if(filename)
delete[] filename;
[/code]

I can verify in the debugger that the buffer is allocated, and the filename is copied correctly. But at the point it releases the wchar array, the application just hangs in the call to delete - no errors I can see. I'm compiling with MS2010. Strangely enough, if I leave it for long enough VS pops up a message saying the application is unresponsive or deadlocked - I'm not using threads in the application.

Thanks very much for any suggestions, I've been looking at this for ages Oo

:)

Share this post


Link to post
Share on other sites
You're actually overrunning your buffer... VS should typically recognize this in debug mode.

filename[filenameHeader->Length] = L'\0';

This goes beyond the length of the array, because you didn't make enough room for the NULL terminator. Try this instead:

wchar_t *filename = new wchar_t[filenameHeader->Length+1];

Share this post


Link to post
Share on other sites
Well you access the array out of bounds for one thing. The valid indices to "filename" are 0 to filenameHeader->Length - 1. You might also be accessing mftBuffer out of bounds.

Why are you conditionally deleting filename? Are you conditionally allocating it? It doesn't appear so from the code you've posted. Vanilla "new" will never return NULL, it throws std::bad_alloc. Even if you were to use the nothrow version, you'd need to wrap all the logic in "if(filename)", not just the delete [] call. Incidentally, delete and delete [] already to NULL detection and are no-ops in this case.

Have you considered using std::wstring?

[quote]
Strangely enough, if I leave it for long enough VS pops up a message saying the application is unresponsive or deadlocked - I'm not using threads in the application.
[/quote]
If your application is not consuming events in the UI thread, then eventually the OS heuristics will deem it unresponsive. If this call is hanging and it is called from the UI thread then this is causing this error message, not deadlocking.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this