Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 428
  • Last Modified:

Array deletion, DEBUG ASSERTION FAILED error

Hello, I am trying to build a menu object to use in a console mode program.
The constructor runs perfectly and sets up the object. The same thing happens with the following function. All the results (visible to me) are the ones expected.

My problems occurs when the Destructor function is called and the place where the error pops up will
be mentioned below .

Here is the class definition :
class WindowMenu
{
public:
     WindowMenu  (int left, int right, int top, int NumberOfMenuEntries,...);
     void Initialize(void);
     SMALL_RECT  *ActiveSurface;
     SMALL_RECT   Client;
     int               NumberOfMenuEntries;
     char          *Entry[MAX_MENU_ENTRY_LENGTH];
     char         *MenuBuffer;
     int               BufferSize;
     int               BkColor;
     int               ForeColor;
     ~WindowMenu(void);
};

void WindowMenu::Initialize(void)
{
     int Width = Client.Right - Client.Left + 1;
     int Height = Client.Bottom - Client.Top + 1;
     BufferSize = Width*Height;
     MenuBuffer = new char[BufferSize];
     ZeroMemory(MenuBuffer, sizeof(MenuBuffer));

     for(int i = 0; i< NumberOfMenuEntries; i++)
     {
          strcat(MenuBuffer, Entry[i]);
          strcat(MenuBuffer,SPACE_BETWEEN_MENU_ENTRIES);
     }
     
}

Here I am just deleting the objects for which i have allocated memory.

WindowMenu::~WindowMenu(void) {

     delete[] Entry[MAX_MENU_ENTRY_LENGTH];  //works fine
     delete[] ActiveSurface; //works fine
     delete[] MenuBuffer;    //OUCH!! ERROR :  DEBUG ASSERTION FAILED in file dbgdel.c line 59
                                //                Expression : _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)  
}


What causes this error and how could I fix it?

Thank You!
0
avramescu
Asked:
avramescu
  • 3
  • 3
1 Solution
 
avramescuAuthor Commented:
Sorry about the low points, It's all I have.
0
 
violent1Commented:
well, let's see and take it slow [well, nobody likes to go slow...but come on...better safe than sorry, right? ;]

anyway.  MenuBuffer is just a pointer to char.  no problem there.  then you go and "new" it.  looks good to me.  you then fill it using strcat, right?  looks good.  just on a glance over and not having the program in front of me, i would agree and say that your program so far is working like you want.

so we move into the destructor.  die destructor!  debug assertion failed!  i hate those.  no, seriously, i do!  in my somewhat limited experience, when i have gotten such an error dealing with char* it has been because i was trying to delete something that wasn't there.  of course, that doesn't appear to be the case here...however, there isn't any reason you can't check, right?

for instance, i might:

if(MenuBuffer != NULL)
{
   delete [] MenuBuffer
   MenuBuffer = NULL;
}

if you would be willing to try that and see if that at least by passes your error for now, that would be great =]

honestly, that is about the only thing i can see right now, since it is but a loley char*

0
 
violent1Commented:
and of course, i happen to forget a semicolon.  but i assume you will catch and correct that ;]
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
avramescuAuthor Commented:
Thanks so much for your answer. While the checkm is very welcome at that point in the destructor, it always turns true, which is very much what I would predict. Also I was positive about this because I was printing the buffer, just for fun, and everything was OK.

However, I have discovered a little thing ( little thing but with a HUGE impact) that you did in the check :

delete[] MenuBuffer;
MenuBuffer = NULL;

So I went back, and revised my destructor, and made it to
have this form

WindowMenu::~WindowMenu(void)
{
     delete[] Entry[MAX_MENU_ENTRY_LENGTH];
     Entry[MAX_MENU_ENTRY_LENGTH] = NULL;   //newly
                                                 added  
     delete[] ActiveSurface;
     ActiveSurface = NULL;                  //same here
     if(MenuBuffer!=NULL)
     {
          delete[] MenuBuffer;
          MenuBuffer = NULL;             //the check
     }
}


And IT WORKS WONDERS! The error vanished which is indeed very inciting. I lost hours trying to fix that thing so I could move on...

Now if you have any idea of why the missing variable = NULL; after array deletion caused that fault, i'd be more than interested to hear it.

Thanks again!
0
 
avramescuAuthor Commented:
I think I'll remove the check because I am certain that MenuBuffer Will never be void...Hmmm...It might be though, if I choose to set up a window without a menu...I'll test this to see how things go.
0
 
violent1Commented:
yeah, you don't need the check if you know that the array will always be there.  it's just habit for me, since the times i have used char* there were times where it wasn't always initizialized [ADT's].

anything i say in regards to the error is purely conjecture and shouldn't be taken as fact or even educated [educated in that i did research, cause i didn't ;]

i have never acatually stepped through the delete through a debugger to see what is going on.  i have been told to do that by professors, so that i know what is happening.  but i mean...geez....lol.  to me, it doesn't seem like it is necessary.  but, if we think about it, perhaps it is.

it's all based around the idea of new NEEDING to be deleted.  once you have newed something, it gets that memory.  the idea of delete [i think] is that it clears that memory.  but UNTIL you set that variable to NULL, the chunk of memory is still referenced.  again, that alone shouldn't be much problem.  but, if we think about a common data type, like an int: what ever memory management is done for int, it's taken care of behind the scenes.  the instant we start using new, we put, in essence, in our hands the memory management.  and, naturally, if we don't follow the proper "etiquette" for that management...we should expect errors.

LOL.  i just typed all that :/ and it could be completely wrong.  but those are my thoughts on this issue anyway ;]

glad you got rid of the error!

0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now