// In a main file, a constructor is called.
ApplicationLayer *appLayer = new AppLayerWin32( hInstance, nShowCmd );
// In another file, the derived class.
AppLayerWin32::AppLayerWin32( HINSTANCE hInst, int nShowCmd )
{
this->hInst = hInst;
if( nShowCmd == SW_HIDE || nShowCmd == SW_MINIMIZE ) {
isVisible = false;
}
else {
isVisible = true;
}
hWnd = NULL;
stringDll = NULL;
uniqueMutex = NULL;
memset(stringLoadBuffer,0,sizeof(stringLoadBuffer));
}
// In a third file lies the base class constructor:
ApplicationLayer::ApplicationLayer(void)
{
LOG_CONST; // Here 'this' pointer is OK.
quitting = false;
homePath = ""; // Here 'this' pointer is corrupted.
gameTitle = "Mephisto AppLayer";
}
Memory bug. *All* suggestions welcome.
Author
I have this bug here that is completely baffling me.
All code that executes before the code shown has been removed, without getting rid of the bug. This includes member constructors, such as for the std::strings homePath and gameTitle.
There is no multithreading going on.
It appears in both Debug and Release build.
The exact point where the corruption moves around when I recompile.
I recently updated VC2005. It appeared but after and before this upgrade.
Any suggestions, no matter how stupid/complex/simple, are welcome. I'm completely out of ideas. And a huuge virtual cookie for the person who can point me in the right direction!
I can't really find the error however I do have a couple suggestions.
I know that VC 2005 actually reports some memory problems while you are debugging, it may tell you where your possible problem is. Also, is the program crashing or just not functioning well.
Second, I have no idea if this is your problem but with VC 2005 I sometimes get errors that have to do with a manifest file that the program embeds. You can turn this off in project options. There is a *slight* chance that this will correct it.
Good luck, and I hope you fix that bug!
I know that VC 2005 actually reports some memory problems while you are debugging, it may tell you where your possible problem is. Also, is the program crashing or just not functioning well.
Second, I have no idea if this is your problem but with VC 2005 I sometimes get errors that have to do with a manifest file that the program embeds. You can turn this off in project options. There is a *slight* chance that this will correct it.
Good luck, and I hope you fix that bug!
I think this maybe your issue,
memset( stringLoadBuffer, 0, sizeof(stringLoadBuffer) );
Let's just say it's a char* for a second. sizeof(stringLoadBuffer) is going to return 4. Probably not what you intended. Now let's say you have this
std::string stringLoadBuffer = "foo";
then did your sizeof( stringLoadBuffer ). It should return roughly 28. Anyway my point is, the third argument of your memset is wrong...at least appears that way to me. It should be something like the number of elements in stringLoadBuffer. That's my semi-educated guess at least or at least the fishiest thing in your code.
Good luck...
Edit:
I'm thinking it's stack corruption but then again...there's no information to let us know otherwise.
memset( stringLoadBuffer, 0, sizeof(stringLoadBuffer) );
Let's just say it's a char* for a second. sizeof(stringLoadBuffer) is going to return 4. Probably not what you intended. Now let's say you have this
std::string stringLoadBuffer = "foo";
then did your sizeof( stringLoadBuffer ). It should return roughly 28. Anyway my point is, the third argument of your memset is wrong...at least appears that way to me. It should be something like the number of elements in stringLoadBuffer. That's my semi-educated guess at least or at least the fishiest thing in your code.
Good luck...
Edit:
I'm thinking it's stack corruption but then again...there's no information to let us know otherwise.
You might also want to post the definition of AppLayerWin32, specifically the stringLoadBuffer. Also, the corruption may actually occur in LOG_CONST, which seems to be a macro.
Quote:Original post by ArmitageIII87
std::string stringLoadBuffer = "foo";
If this is the case, you have a severe bug in using memset on a non-POD class.
In C++ memset should never be necessary. If stringLoadBuffer is a std::string, then it is automatically initialised to "". If it is a char* it should be changed to a std::string anyway. If it is any other class, it's constructor should initialise it.
This may not be what is causing the error, but it should be changed anyway.
This may not be what is causing the error, but it should be changed anyway.
Quote:If this is the case, you have a severe bug in using memset on a non-POD class.
I understand what I wrote and yes using memset on non-POD is a problem. Thanks for saying something though...it could have led a newbie astray. Who knows what stringLoadBuffer is...it was left out. I was just making the point that the way he's using memset was not correct based on minimal information. Anyway...LOG_CONST is interesting as well.
Author
class AppLayerWin32 : public ApplicationLayer { private: // Used to make sure only one instance of the game is running. HANDLE uniqueMutex; HINSTANCE stringDll; HINSTANCE hInst; HWND hWnd; bool isVisible; typedef std::pair<std::string, std::string> configPair; typedef std::map<std::string, std::string> configMap; configMap configs; InputManagerDirectInput input; char stringLoadBuffer[256]; // Lots of methods but no data follows.As you can see, stringLoadBuffer is an array of char. It is btw used to as a buffer to load strings from a string table resource. I've checked the sizeof(stringLoadBuffer), it's 256. Still, I'd prefer it a little more c++-like, but the function LoadString from the API requires a char*. Suggestions are welcome.
The LOG_CONST is indeed a macro. I did however remove it at one point and the bug remained.
I haven't heard of the manifest file thing before. I tried shutting it off, but now it can't find msvcp80.dll and a few other dll's. But I'm looking into this one.
Thanks for the replies all of you.
I'm sure you know this, but std::string does have a function called c_str that may be of use to you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
