Jump to content
  • Advertisement
Sign in to follow this  
polaris2013

Very strange win32 problem occuring upon PeekMessage

This topic is 4131 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

I've got a class and one of it's data members is a string that maintains the filename I'm working on. Works fine except whenever I set this string from my Open() function it gets allocated to 0x0012fa70, which I think must be a special address because whenever the message handler runs
fMessage = PeekMessage(&msg, NULL, 0U, 0U, PM_REMOVE);
The string gets deallocated! Note this doesn't happen whenever the string gets allocated from SaveAs() but that my string will be located different address, too. Same target filename, though. I guess since I'm using the debugger that it consistently allocates to the same addresses all the time, cuz I've run the test about a dozen times, and PeekMessage always messes up my string when it's located at 0x0012fa70. (I single stepped with a watch on my Filename string member to see when it got messed up) Any hints on how to make PeekMessage stop scribbling on my memory? Here's my system info: Microsoft Visual Studio 2005 (VC Express) Version 8.0.50727.762 (SP.050727-7600) Microsoft .NET Framework Version 2.0.50727 Windows Server 2003 R2 Platform SDK WinXP Pro edit: accidentally C&Ped wrong PeekMessage first time. fixed now.

Share this post


Link to post
Share on other sites
Advertisement
0x0012fa70 is probably a stack address. It's likely that the string gets deallocated when the variable leaves the function scope. If that's the case, declare the string on the heap using "new" or "malloc" as the case may be.

Share this post


Link to post
Share on other sites
I doubt PeekMessage is actually at fault. Please post the code that allocates the string in question, particularly any context which would show the string's scope and lifetime (i.e. stack allocated vs heap allocated, as LessBread addressed).

Share this post


Link to post
Share on other sites
Okay, it took me a while to figure out how to use the call stack, now I'm back. Here it is for Open():

QuadsEngine.exe!stringcopy(char * & a=0x0012fa70, const char * b=0x0012fa70) C++
QuadsEngine.exe!CGame::ReadScenario(const char * sz_filename=0x0012fa70) C++
QuadsEngine.exe!CGame::EditorLoad(char * sz_filename=0x0012fa70) C++
QuadsEngine.exe!WinProc(HWND__ * hwnd=0x00010614, unsigned int msg=273, unsigned int wParam=40002, long lParam=0) C++
user32.dll!77d48734()
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
user32.dll!77d48816()
user32.dll!77d489cd()
user32.dll!77d4ca67()
user32.dll!77d496c7()
QuadsEngine.exe!CGame::GameLoop() C++
QuadsEngine.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * __formal=0x00000000, HINSTANCE__ * __formal=0x00000000, HINSTANCE__ * __formal=0x00000000) C++
QuadsEngine.exe!__tmainCRTStartup() C
QuadsEngine.exe!WinMainCRTStartup() C
kernel32.dll!7c816fd7()


Here's stringcopy (I wrote my own because I wasn't sure how the console one would work with Windows):
char* stringcopy(char*& a, const char* b)
{
int len=0;
while(b[len++]!='\0'){}

a = new char[len];
for(int i=0; i<len; i++) a=b;
return a;
}


Both of them use that same function to set the string, here it is in Open:

int CGame::ReadScenario(const char* sz_filename)
{
//irrelevant stuff
FILE* pFile;
//Open File
stringcopy(m_szScenarioFile, sz_filename); //this one, in the end, doesn't work
pFile = fopen(sz_filename, "r");
if(pFile == NULL)
{
return RET_ERROR;
}
//other stuff
}


Here it is in SaveAs (also Save, when the parameter passed is NULL):

E_VAL CGame::EditorSave(LPSTR sz_filename)
{
FILE* pFile;

if(sz_filename!=NULL)
{
//Save As
pFile = fopen(sz_filename, "w");
stringcopy(m_szScenarioFile, sz_filename); //this one works
}
else
{
//Save
pFile = fopen(m_szScenarioFile, "w");
}

if(pFile == NULL)
{
return RET_ERROR;
}
//other stuff
}


I think I noticed an error that may have an impact while I was writing this up, I'll look into it now (but I wanted to post first since the more eyes looking at it the better!).
edit: okay I just fixed that memory leak on stringcopy by only passing"b" to it, but that didn't fix nothin'. I'll leave my post as is, though, for context's sake.

[Edited by - polaris2013 on March 27, 2007 5:41:06 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by polaris2013
Okay, it took me a while to figure out how to use the call stack, now I'm back. Here it is for Open():

QuadsEngine.exe!stringcopy(char * & a=0x0012fa70, const char * b=0x0012fa70) C++
QuadsEngine.exe!CGame::ReadScenario(const char * sz_filename=0x0012fa70) C++
QuadsEngine.exe!CGame::EditorLoad(char * sz_filename=0x0012fa70) C++
QuadsEngine.exe!WinProc(HWND__ * hwnd=0x00010614, unsigned int msg=273, unsigned int wParam=40002, long lParam=0) C++


It looks like you're trying to copy the string to itself. What does the call to EditorLoad look like? How is sz_filename declared?

strcpy (and related functions) work with windows, although strncpy is safer. You probably should use std:string anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by LessBread
[...]You probably should use std:string anyway.
And where you can't (old APIs that require non-const character arrays), vector<char> works just fine (plus it's trivial to convert from vector to string and back).

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!