# Odd _BLOCK_TYPE_IS_VALID error

This topic is 4234 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I get this error whenever I delete an array of my SB_Data objects. This is a very simple class, so I've pasted the header and source files below. The class's header (SB_Data.h) is:
Quote:
 #pragma once class SB_Data { public: static const uint8 TYPE_NULL = 0x00; static const uint8 TYPE_INT = 0x01; static const uint8 TYPE_BOOL = 0x02; static const uint8 TYPE_FLOAT = 0x04; static const uint8 TYPE_STRING = 0x08; union { int32 intVal; bool boolVal; float32 floatVal; char *strVal; }; uint8 type; SB_Data(void); SB_Data(int32 val); SB_Data(bool val); SB_Data(float32 val); SB_Data(char *val); ~SB_Data(void); };
And it's source file (SB_Data.cpp) is:
Quote:
 #include "main.h" SB_Data::SB_Data() { intVal = 0; type = TYPE_NULL; } SB_Data::SB_Data(int32 val) { intVal = val; type = TYPE_INT; } SB_Data::SB_Data(bool val) { boolVal = val; type = TYPE_BOOL; } SB_Data::SB_Data(float32 val) { floatVal = val; type = TYPE_FLOAT; } SB_Data::SB_Data(char *val) { strVal = val; type = TYPE_STRING; } SB_Data::~SB_Data(void) { if (type == TYPE_STRING) { delete strVal; } }
Now, if I execute the code:
Quote:
 SB_Data *test = new SB_Data[2]; delete test;
I get the following runtime error:
Quote:
 Debug Assertion Failed! Program: c:\Files\Projects\SlaughterBots\debug\SlautherBots.exe File: dbgdel.cpp Line: 52 Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts. (Press Retry to debug your application)
Pressing Retry breaks the application on the line with the 'delete'. I've done some research on this error message, and it's supposed to occur when you try to do an operation on an invalid pointer, or if the block of data being pointed to is somehow corrupted. It seems to be most commonly associated with trying to delete the same pointer twice. However, I can't see how any of that could have happened in this case. Now the really strange part is that it only happens if I use 'new' to allocate the memory, and only if it's allocated as an array. So if I allocate it with "new SB_Data[1]" it still generates the error when I delete it. However, if I allocate it with "new SB_Data" or "malloc(sizeof(SB_Data) * 2)" it will delete without incident. Also, using 'free' instead of 'delete' just causes a different, even less informative runtime error. This only seems to occur for the SB_Data class. If I do the same code with another class, or with a basic data type, it works fine. So I'm pretty sure it's something to do with how I coded my class. However, it's such a simple, straight forward class, it's hard to imagine where the error could be. I could just go through and replace all instances of 'new' with 'malloc', but I'd honestly much rather know why the problem is occurring in the first place and actually fix it.

##### Share on other sites
I think your problem is that when you allocate an array with new, you have to use delete [] to delete it. For example:

SB_Data *test = new SB_Data[2];delete [] test;

SB_Data *test = new SB_Data[2];delete test;

If that doesn't fix the problem, please tell me.

##### Share on other sites
Yep: always delete[] what you new[]. Also, using malloc() (and family) in C++ is almost always bad form.

You may find these FAQs very useful.

##### Share on other sites
Huh. That's interesting. Thank you. That does indeed fix the problem.

I'm kind of mystified that I haven't encountered this before, as I've been programming C++ for years. I just poked around in both of my C++ books, and found that the one I usually use, which was published in 91, never seems to mention the delete[] syntax, while the other one, from 95, that I rarely touch, does describe it. Is this something that was added in an update to C++ between 91 and 95, or has it always been there and my first C++ book is just incomplete?

And I know malloc/free in C++ is bad form, and I normally wouldn't use them. It was just another avenue of trouble-shooting, to see if it made a difference.

##### Share on other sites
I don't know when this was added. But the error you're getting is a MS specific implementation of debug heap.

This error is reported on unusual memory access. In case of arrays the data allocated is stored differently, since it also needs to store the number of allocated elements - this depends on compiler.

Using regular delete is also ambigous with respect to class operator delete.

##### Share on other sites
C++ wasn't really standardized as a language until 1998; good, widespread compiler support for actual C++ wasn't established until 2003 or so.

Any resource (books, articles, compilers, etc.) from before 1998 that supposedly deals with C++ is next to worthless. The language itself, standard library, and generally accepted best practices have come a tremendously long way in the past 9 years.

I'd really strongly recommend reading through the entire C++ FAQ site I linked earlier. If you're relying on 12 and 16 year old resources, you will have a lot of gaps and flaws in your knowledge. 12 years is eternally outdated in the software industry; even 5 years is, in many cases, pushing it. Anything older than 3-4 years in the C++ world is highly suspect, unless it is very well known and accepted by the elder C++ community.

Some might go so far as to say you don't actually know C++, but rather some Frankensteinian zombie-language from the past.

Please tell me you're not also using Visual C++ 6 [wink]

##### Share on other sites
Quote:
 I'd really strongly recommend reading through the entire C++ FAQ site I linked earlier. If you're relying on 12 and 16 year old resources, you will have a lot of gaps and flaws in your knowledge. 12 years is eternally outdated in the software industry; even 5 years is, in many cases, pushing it. Anything older than 3-4 years in the C++ world is highly suspect, unless it is very well known and accepted by the elder C++ community.Some might go so far as to say you don't actually know C++, but rather some Frankensteinian zombie-language from the past.

Wow. Nothing like a really extreme statement of the case to make me want to back away slowly and leave the conversation.

I am, however, scanning over this site you linked to. The vast majority of it is identical to what I already know, but I've found a few random details here and there that are handy. Fortunately, my education in C++, and the principles of object oriented programming in general, are not based solely off these books, and so far it seems that the books are still like 99% correct (especially since neither of them really address the standard libraries too deeply, and I believe those have changed FAR more then the core language).

And no, I'm not using Visual C++ 6. I'm up to date with Visual C++ Express 2005 (and I just double-checked to make sure that this is, indeed, still the newest version).

##### Share on other sites
Quote:
 Original post by HeruFeanorI'm kind of mystified that I haven't encountered this before, as I've been programming C++ for years.

!

You may have spent years programming what was, at any given time, considered "C++", but you sure haven't been programming what is *currently* considered C++ (which has existed for years but was largely ignored for a while and is still fighting to gain proper recognition).

... Well - I suppose much depends on how many years we are talking about?

Quote:
 the one I usually use, which was published in 91, never seems to mention the delete[] syntax, while the other one, from 95, that I rarely touch, does describe it. Is this something that was added in an update to C++ between 91 and 95, or has it always been there and my first C++ book is just incomplete?

Ummm... Wow. That's a lot of years. :)

I have no idea what happened to C++ between 1991 and 1995, to be honest. I do know that a lot of stuff got standardized in 1998, and revised in 2003, creating the language we now know and love - okay, tolerate.

But in this language currently called C++, we use namespaces instead of prefixing everything with tags, use initializer lists for constructors (so that we actually initialize things instead of assigning to them), don't write (void) for function prototypes, and use a real string type, provided by the library, called std::string.

Oh, and it's never been terribly good style to *rely on* pragmas, or to use a set of constants where an enumeration is clearly indicated (certainly there's no need to use power-of-two values; a discriminated union should only be in one state.) Although we tend to use unions rather more sparingly anyway, since we can't properly stuff types like std::string into them - the runtime won't know which, if any, destructor to call, since it isn't smart enough to grok our union-discriminator.

But as it happens, a third-party library knows how to work around that issue, too: check out boost::variant.

Quote:
 Wow. Nothing like a really extreme statement of the case to make me want to back away slowly and leave the conversation.

That's a shame. (Rhetoric of this sort is often seen as necessary around here to get the OP's attention; and in any case, no real harm is intended - just as we don't really *mean* that various language constructs are evil.)

Quote:
 and so far it seems that the books are still like 99% correct (especially since neither of them really address the standard libraries too deeply, and I believe those have changed FAR more then the core language).

But you see, that really makes them more like 99% incorrect *by omission*, because the standard library of a language is as close to part-of-the-language as it is possible for code written in that language to be. In C, would you try to reinvent stdio.h?

1. 1
2. 2
Rutin
20
3. 3
khawk
16
4. 4
A4L
14
5. 5

• 12
• 16
• 26
• 10
• 11
• ### Forum Statistics

• Total Topics
633756
• Total Posts
3013708
×