Invalid Address specified to RtlValidateHeap


I've made a screensaver, which when closed under debug mode of VC6 brings up a messagebox with

"User breakpoint called from code at 0x77f75a58"

In the debug window it says..
HEAP[IntelliScreenSaver.scr]: Invalid Address specified to RtlValidateHeap( 00870000, 0087303C )

I was just wondering what all that meant? Memory leaks? And if so is there anything I can do to track down the errors? It's closed by using PostMessage(WM_CLOSE, 0, 0l); (that was there in the framework I started with)

Who is Participating?
SteHConnect With a Mentor Commented:
This means that a variable which you are trying to free does not belong to the heap (anymore?) It can happen if you try to deallocate memory twice. Set pointers to 0 after deallocation a it should be safe if you are using new and delete.
delete 0;
does nothing.
shifty_mcAuthor Commented:
Oh, well that was simple - deleted a line in the OnDestroy method saying
delete currentplugin;
and no more errors.

I'm confused tho - I haven't deleted it elsewhere - where's it gone?

currentplugin is a pointer to a class derived from CPlugin which is created at runtime, although it's not created with new directly...
currentplugin = CPlugin::GetCurrentPlugin(m_plugin);
and in my CPlugin class I have
CPlugin* CPlugin::GetCurrentPlugin(CString &TypeName)
      if (TypeName == "sometype") return new CSomeclass();
      return NULL;

AlexFMConnect With a Mentor Commented:
This means CPlugin class deletes itself somewhere. Try to search it's source code for "delete this". Try to set breakpoint in your CPlugin-derived class destructor and see that it is called (this means, you don't have memory leaks) and from where.
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

shifty_mcAuthor Commented:
Hmmm, no "delete this", apart from in my main class.

I'm not normally a c++ programmer, and I've got memory leaks all over the place - without the "delete currentplugin" though I don't get the messagebox, but get a list of memory leaks in the debug window.

Where should my delete's go then? And why is the delete currentplugin not working? I tried putting a breakpoint on the CPlugin derived destructor, and no change in the debug window - I take it that means it isn't called? This is by far the biggest thing I've done in C++/VC6 so haven't really used the debugger/breakpoints before.
In VC6++ I get memory leaks from time to time which are not real leaks. Memory allocated during CRT startup is not released when the memory checking occurs but gets deleted later on. This is displayed as leaking memory.

You can put

static struct _test
    _test ()
        _CrtSetBreakAlloc (1689); // change the number to one you find for a source of leak {xxx}.
} test;

into your code to see where the allocation occurs and whether it should have been deleted already.
OK, my guess was wrong. Set breakpoint in the line

delete currentplugin;

and check value of "this" and value of currentplugin - is it equal to initial value of this pointer when object was created.

By the way, you can use breakpoints only if you run program under debugger - Go command and not Run.
shifty_mcAuthor Commented:

It was just something very simple... in my CPlugin class I had an array of strings created with new, that I had been deleting with a plain old delete instead of delete[]. When I changed that it solved everything. No more memory leak notifications or message boxes!

Thanks for your time.

SteH - I put your code in before I noticed that error - but am unsure what it actually does. When I used it, it didn't seem to change anything. I didn't pay too much attention tho it has to be said - noticed where I was going wrong soon after.

I'll split the points evenly, cheers.
The code allows you to break on memory allocations which occur early during the program. If you put the line
_CrtSetBreakAlloc (1689);
in a file using MFC it is best placed in the CWinApp derived class constructor or init. But a lot of allocations happened already at that time. I had notifications about leaks with numbers like 70 and could not find them before. Using that approach I found that the allocations was done for some constant strings. Not allocated using malloc or new so no need to release them. But when the check for leaks was done these were reported. But they could be safely ignored.

But happy that you found your problem anyhow.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.