# .dll heap problem

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

## Recommended Posts

Helo My game.exe has static linkage to engine.dll which loads plugins like menu.dll. But when I call menu.dll function from game.exe I first get _CrtIsValidHeapPointer assertion and then heap problem. code: // engine.dll -> menu.dll Root::getSingleton().getIMenu()->LoadElement(...) What should I do?

##### Share on other sites
Hello...

Quote:

If i understand it correctly, Root belongs to menu.dll, and you want to get a pointer to it from the engine.dll.

First of all, try to subdivide the above command into smaller commands. E.g.

CRoot root = Root::getSingleton();IMenu* menuHandler = root.getIMenu();menuHandler->LoadElement(...);

Observe the returned values. I suspect that the first line doesn't return a valid singleton!!! If it returns a valid one, and if you are sure you already have initialized the menuHandler getIMenu() suppose to return, then i think that you don't use menu's root but an other root which is build into engine.dll. (Does this make any sense???)

What i have to suggest is:
1) Try to get a pointer to Root, without calling getSingleton(). The usual approach to singletons is through a templated class which handles the basic functionallity in a header file. And you have to include this header in every dll/exe which needs it.

If this is the case then try to get a pointer to it, through an other function exported from menu.dll. Something like:

CRoot* GetRoot(void);

This way you will be sure that you get the singleton from the menu.dll. And you are sure that is valid.

2) If you are sure that root is valid, and the same as the one in menu.dll, then there is something with the menuHandler. Check to see if at the time you are calling getIMenu() you have a menu handler initialized (i suspect it is automatically initialized with the singleton !?!?). Maybe the returned pointer is invalid.

3) Final, if everything seems normal and ok check to see what's happening inside LoadElement(). Maybe this is the real problem. Try to debug LoadElement() through engine.dll.

Hope this helps. Sorry for my english. I'm not sure if the above work. They are just random thoughts.

HellRaiZer

##### Share on other sites
This is in game.exe

// I call root from engine.dll to obtain interface pointer to menu
// I call menu function throu interface

I get assert _CtrIsValisHeapPointer and debug heap problem!

I dont think there s a problem with singleton class.

##### Share on other sites
Oh, and I forgot:

I get this arror on function exit, after the function body
executed ok so there must be something wrong with function call I
think and not with singleton.

##### Share on other sites
As far as i know, when a function exits in debug mode, the compiler places some extra source code for checking the esp register. But this has nothing to do with your problem. It has to do with function's calling convention (__stdcall, __thiscall, etc.).

Maybe, in your situation, and because the function is __thiscall, the compiler also checks if "this" (ecx register) is still valid. This is possible. If you make the same call from the dll itself, does it produce the same error?? Are you sure you aren't "destroing" "this" somehow??

Try to export a "C" linked function from the dll which will do the same thing in one call, and see if it produce the result.

E.g.

// menu.dllextern "C" __declspec(dllexport)bool LoadElement(...){  return Root::getSingleton().getIMenu()->LoadElement();}// engine.dll// pfnLoadElement is a pointer to the above function, obtained via GetProcAddress()// I don't know if this is possible in your case...// Then call it...pfnLoadElement(...);

Just guesses again :)

HellRaiZer

EDIT : In case you still have problems, there is one way to find out what's going on in there, but it's the hard way (tm). Mark the end of the function somehow (do a printf() using a unique string). Open a disassembler/debugger, and search for the string. There are two options now. Either try to analyze the dead listing yourself, or debug the code up to this point to see where exactly is the problem.
I know this doesn't help very much, but it's a solution. If you do all these, and you have problems understanding the source, try to cut the function's asm (the exit part only) and post it here. We will see what we can do!!!

HellRaiZer

##### Share on other sites
Make sure both projects use the same version of the run-time under the Code Generation portion of the C/C++ folder in the Configuration Properties (VS.NET) or the Code Generation portion of the C/C++ tab in the Project Settings (VS6). This is sometimes a source of error between modules.

Magius

##### Share on other sites
Don't use singletons across DLLs. Period.

Another reason why I strongly dislike singletons.

##### Share on other sites
I found the problem.

It was std::string !!!!

I passed std::string fileName as a parameter into a function!
It should be either reference or const char* becouse stl means
tamplate :-)

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 11
• 10
• 9
• 15
• 22