Jump to content
  • Advertisement
Sign in to follow this  
davidkosenina

.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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
Hello...

Quote:

code:
// engine.dll -> menu.dll
Root::getSingleton().getIMenu()->LoadElement(...)


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 this post


Link to post
Share on other sites
This is in game.exe

// I call root from engine.dll to obtain interface pointer to menu
IMenu* pMenu = Root::getSingletonPtr()->getMenu();
// I call menu function throu interface
pMenu->LoadElement()

I get assert _CtrIsValisHeapPointer and debug heap problem!

I dont think there s a problem with singleton class.

Share this post


Link to post
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 this post


Link to post
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.dll
extern "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 this post


Link to post
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 this post


Link to post
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 :-)




Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!