Assertion failure on memory deallocation C++ CLR [solved]

Started by
8 comments, last by ak-73 15 years, 5 months ago
I was being an idiot :| Really need to make sure i'm releasing the right pointer. I accidentily deallocated the the passed string so of course it was going to be annoyed when i tried to do it again :$ [Edited by - Guthur on November 19, 2008 1:57:06 PM]
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Advertisement
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Must be something in the code fragment :S

I seem to get an assertion failure at the last string delete (sMain). BLOCK_TYPE_IS_VALID. This is C++ CLR. Any ideas?

Cheers
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Quote:Original post by Guthur
Must be something in the code fragment :S

Are you saying that is why the first two posts show nothing? Put code in [ source ] [ /source ]
I am going to stop now because it obviously doesn't like it :|

Its only a memory leak :p

I allocated a dynamic char array pass it and then delete it, this causes the error on the delete. Strange thing is i do this for 3 strings and it only fails on one :s

Edit - I was putting the code in source tags

Here is tha allocation and deallocation, nothing happens inbetween except the strings get passed to be read. It fails on the deallocation of sMain.

		wchar_t* path = 0;		unsigned pathStrLen = 0;				wchar_t* profile = 0;		unsigned profStrLen = 0;				wchar_t* sMain = 0;		unsigned sMainStrLen = 0;		strArray = filePath->ToCharArray();		pathStrLen = strArray->Length;		path = new wchar_t [pathStrLen+1];		Marshal::Copy( strArray, 0, IntPtr(path), pathStrLen );		path[pathStrLen] = '\0';		strArray = shaderProfile->ToCharArray();		profStrLen = strArray->Length;		profile = new wchar_t [profStrLen+1];		Marshal::Copy( strArray, 0, IntPtr(profile), profStrLen );		profile[profStrLen] = '\0';		strArray = shaderMain->ToCharArray();		sMainStrLen = strArray->Length;		sMain = new wchar_t [sMainStrLen+1];		Marshal::Copy( strArray, 0, IntPtr(sMain), sMainStrLen );		sMain[sMainStrLen] = '\0';


		delete [pathStrLen+1] path;		path = 0;		delete [profStrLen+1] profile;		profile = 0;		delete [sMainStrLen+1] sMain;		sMain = 0; 


[Edited by - Guthur on November 19, 2008 9:17:45 AM]
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Quote:Original post by Guthur
I am going to stop now because it obviously doesn't like it :|

Its only a memory leak :p

I allocated a dynamic char array pass it and then delete it, this causes the error on the delete. Strange thing is i do this for 3 strings and it only fails on one :s

Edit - I was putting the code in source tags

Here is tha allocation and deallocation, nothing happens inbetween except the strings get passed to be read. It fails on the deallocation of sMain.

*** Source Snippet Removed ***

*** Source Snippet Removed ***


1. Is there a reason you don't use the standard library's string?

2. If you'd use it, you could create
string FilePath::getPath();
Because the repetition in your code calls for putting that stuff inside a method.

3. Don't specify size with delete[]. delete[] itself is good enough.

4. If you are really serious about coding, one of the best things to learn is basic assembly language and how to read a debugger. Can be self-taught in a few weeks.

Alex
Already done assemblier, a bit anyway, 6502 back at school and the IBM assemblier. Its ok but to be honest I want to have tangible results, in terms of functional applications, and to be playing with assemblier would just be a major distraction. Also i'd like to concentrate on C++ for awhile, there is alot to learn about. And then when you throw in C# and .NET :s

Getting things working between a C# winform and a win32 c++ dll has been problematic to say the least :| I'm getting close, this is the last real issue i think, i hope. Strings have been an issue and yes ideally i would want it in a function but like i said they are being problematic :p I had it in a function but then realised it was a dirty memory leak. :

On a side note for anyone to even suggest there is some sort of standard to character representation is having a laugh :| :p

As for not using string ya there was a reason :p. STL has a few issues with managed code and i was trying to keep it seperate, though it probably wouldn't arise in my case.

Thanks on the delete[] info, i would have probably went for ages without realising that :$
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Quote:Original post by Guthur
Already done assemblier, a bit anyway, 6502 back at school and the IBM assemblier. Its ok but to be honest I want to have tangible results, in terms of functional applications, and to be playing with assemblier would just be a major distraction. Also i'd like to concentrate on C++ for awhile, there is alot to learn about. And then when you throw in C# and .NET :s


My point was not in learning assembly to code in but to use the debugger meaningfully. Because looking at the disassembly and stepping through it (and keeping tabs on what happens in memory) you'd be able to *easily* see for yourself where things go wrong.

The point to learning assembly is to not be as dependent on outside help for finding and fixing bugs. (As well as understanding C++ better. Without learning basics (only basics!) of assembly quite a few things about C++ might not get properly understood.)

But you're right: understanding most of C++ properly has to have priority, I guess. :-)
But don't think learning the basics of assembly has no relevance to understanding C++ properly. You'd be dead wrong. But most importantly it's important is for *debugging*.

Alex
Point taken Alex, its a fair point and one I will definitely take on board. I wish i had the time to delve into assemblier is all i meant :) If the problem is that deep then i'm just going to let it leak and mark it down to be looked at later.

I have spent long enough gluing these projects together, I want to get back to making the application :). I now know a lot more about making dll's and creating wrappers for managed code to use unmanaged libs, it should be worthwhile knowledge i think.
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Quote:Original post by Guthur
Point taken Alex, its a fair point and one I will definitely take on board. I wish i had the time to delve into assemblier is all i meant :) If the problem is that deep then i'm just going to let it leak and mark it down to be looked at later.

I have spent long enough gluing these projects together, I want to get back to making the application :). I now know a lot more about making dll's and creating wrappers for managed code to use unmanaged libs, it should be worthwhile knowledge i think.


Sure. But if you want to drastically improve your C++-Skills beyond what can be picked through coding itself, read first Effective C++ and then pick up some assembly basics until you understand exactly what your application is doing in disassembly.

Alex

This topic is closed to new replies.

Advertisement