3

I keep encountering this "Debug assertions failed!" error when I run my program in debug mode. I tried looking this error up on the visual C++ website but the explanations are too advanced for me and they don't have any resemblance to what my best guess as to the problem is.

I have went through my code and narrowed down the point at which the error occurs. It seems to be happening in the portion of code where I manually delete a whole bunch of heap arrays before the computer moves onto the next part of the program. When I comment out the section that frees up the old heap arrays, the program runs perfectly fine.

Any idea whats going on here? My knowledge in programming is still relatively basic.

Thanks

I'm using Visual C++ 2008.

More information:

The break point triggers at this block of code:

 void operator delete(
    void *pUserData
    )
{
    _CrtMemBlockHeader * pHead;

    RTCCALLBACK(_RTC_Free_hook, (pUserData, 0));

    if (pUserData == NULL)
        return;

    _mlock(_HEAP_LOCK);  /* block other threads */
    __TRY

        /* get a pointer to memory block header */
        pHead = pHdr(pUserData);

         /* verify block type */
        _ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));//<---- break point triggers 

        _free_dbg( pUserData, pHead->nBlockUse );

    __FINALLY
        _munlock(_HEAP_LOCK);  /* release other threads */
    __END_TRY_FINALLY

    return;
}

This code is from the tab: dbgdel.cpp

The section of my code that that I've "narrowed down" that causes this problem is this:

delete [] topQuadanglesPositions;
delete [] fourClamps;
delete [] precaculatedClamp1;
delete [] precaculatedClamp2;
delete [] precaculatedClamp3;
delete [] precaculatedClamp4;
delete [] area;
delete [] hullConfiguration;
delete [] output;
delete [] prunedListClamp1;
delete [] prunedListClamp2;
delete [] prunedListClamp3;
delete [] prunedListClamp4;
delete [] numValidLocations;

If i comment out this section, the program runs fine.

Himanshu
  • 4,327
  • 16
  • 31
  • 39
Faken
  • 11,352
  • 17
  • 59
  • 74
  • Please, be more specific. "Deleting a bunch of heap arrays" is not enough information to know what's going on... – Diego Sevilla Sep 20 '10 at 19:59
  • Pretty hard to debug code without any code to debug. A better question is why you're freeing things manually. Use `std::vector`. – GManNickG Sep 20 '10 at 19:59
  • Why do you need "narrowing down the point" when you can just hit "Break" button when the message appears and look at the call-stack window to see where exactly it happend. – Yakov Galka Sep 20 '10 at 20:01
  • General advice, per GMan - don't use new/delete, use RAII: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#C.2B.2B_example – Steve Townsend Sep 20 '10 at 20:02
  • @Diego: sorry, I still don't know proper terminology for things but its a section of code where I do this: delete [] tempArray; at the very end of a section of program to clean up memory no longer in use. @GMan and Steve: In the future i will not do that anymore, but right now I already have written an 11K lines of code program that uses it so there's not much point changing it over right now. – Faken Sep 20 '10 at 20:03
  • @ybungalobill: When i hit break it brings me to some code that i didn't write and have no idea what it dose. – Faken Sep 20 '10 at 20:05
  • if you've narrowed down the problem space, post your code! We cannot read your mind, help us help you. – Sam Miller Sep 20 '10 at 20:07
  • 3
    @Faken - arguable. It may be quicker to revisit your new/delete usage and replace it than to debug what you have now. Also makes for an easier maintenance job down the line. It seems you are not at risk of breaking the current code since it's corrupting the heap, as far as can be seen from your data. – Steve Townsend Sep 20 '10 at 20:08
  • 1
    @Faken Right. When you get there open Debug->Window->Callstack (or something like that) and then double click the items in the list that appears to see how your program got to this code. – Yakov Galka Sep 20 '10 at 20:10
  • 1
    @Faken: You're code is already broken, what could you lose by making it cleaner and better? (And holy hell that's too many deletes.) – GManNickG Sep 20 '10 at 20:10
  • @Gman: with my level of skill, a whole lot can go wrong with even such a simple fix as you say. 99% of the program works, actually 100% will work if i comment out that section of code, but that's a duct tape fix that i don't want to do. I don't think there is anything technicaly wrong with using new and delete, its just maybe cleaner to do it another way. – Faken Sep 20 '10 at 20:22
  • 1
    But since you are choosing to take on the unnecessary burden of managing your own memory, your program is already composed of new/delete duct tape wrapping the business logic. Strip out the duct tape and leave the logic, life will be a lot easier for you afterwards. ESPECIALLY if you are learning. Now is the time to build good habits. – Steve Townsend Sep 20 '10 at 20:45

3 Answers3

7

Your code is corrupting the heap. The first snippet is from the C runtime library, the assert is telling you that your program is passing a bad pointer value to the delete operator.

Commenting out the delete statements merely hides the problem. It will come back to haunt you a different way when you keep developing the program. There are some debugging tips in this thread. Learning how to catch these kind of bugs is a rite of passage for any C or C++ programmer. Welcome to the group.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks for the simple explanation! I'll look through that thread and see if i can pick up any ideas on whats going on. – Faken Sep 20 '10 at 20:26
  • Thanks to your advice, i found the problem. I had linked two pointers to the same array and attempted to delete the data the two pointers pointed to, which was fine for the first delete but the second time around produced the error. – Faken Sep 20 '10 at 20:37
  • 2
    That was quick. Congratulations. – Hans Passant Sep 20 '10 at 20:51
2

Assertions are statements which only evaluate when you are running in debug mode (Cheap debug checking).

For instance, this would fail assertion in debug, but would not cause an error in release:

ASSERT(1 == 2);

It's likely that some method you are calling expects a certain input and isn't getting it, but it doesn't cause an immediate error (So your code works in non-debug mode.)

Hopefully that's helpful.

If you can post your specific code, someone can probably help you with a more specific response.

Aaron H.
  • 6,407
  • 5
  • 25
  • 30
1

Asserts happen when program gets into illegal state. Assert is is written in code by programmer to notify him when something goes bad. You must start debugging from your IDE and press break when you get assert message. Than you should see what is condition in assert, like assert(i > 1024) and make sure that this never becomes true. Maybe you have some comment about meaning of assert, you must find line where it happens and why.

watbywbarif
  • 6,487
  • 8
  • 50
  • 64