Skip to main content
GameDev.net gamedev.net
🔒 Locked

memory access mismatch: how should I debug this?

Started by irreversible Jan 2, 2011 at 7:29 PM 8 replies 850+ views
Original Post
irreversible
irreversible
I'll be concise and to the point: I have a class that has a member string. In its constructor I'm copying an argument string (pointer) to the member string (static array). Using all methods, however (wcscpy, wcscpy_s and one-by-one character copy) the first four characters aren't copied, but the loop/copy routine exits with the string copied, always starting from the fifth character (this seems to happen for all instances of the class).

Usually I'd expect this to be a memory leak/buffer overrun problem, but this is happening very early in my startup code and, quite frankly, since it also happens at the top of the constructor with no other threads running and inside all instances of the class, I'm not sure what why or how could be causing this. To the best of my knowledge, this issue just appeared out of nowhere without my being able to attribute it to any noteworthy change (and, yes, I've tried a full rebuild). This happen when running from the command line as well as from the IDE.

Any ideas or suggestions where to start looking?

Edit - oh-oh! I just noticed something extra cool:

//ClassName is expected to be "windowclass";
WindowClass.lpszClassName = (LPWSTR)ClassName;

When I inspect ClassName, it's "owclass" while WindowClass.lpszClassName displays a proper "windowclass".
SiCrane
SiCrane
What are the exact types of all the variables involved?
irreversible
irreversible
Quote:
Original post by SiCrane
What are the exact types of all the variables involved?


//class member
wchar_t ClassName[128];

//constructor argument
wchar_t* pClassName;

WindowClass.lpszClassName is LPCWSTR (WindowClass is WNDCLASSW)


Something further that is noteworthy, but highly perplexing - I'm error cheching my CreateWindowExW() call:

Handle = CreateWindowExW(...);if(Handle == NULL)   RAISE(hell);


Tracing this code shows Handle as NULL all the way through and the check on the handle passing despite that.
irreversible
irreversible
Okay, there is definitely more going on here. It's as if memory inside the class' memory space is shifted by some small offset. I moved my initialization code to the very top of the program and the same symptoms appear: when stepping through it, all variables inside the constructor are set incorrectly. But - not entirely randomly. Eg: 

        iID = 0;	iX = iRestoredX = 100;	iY = iRestoredY = 100;	iWidth = iRestoredWidth = 800;	iHeight = iRestoredHeight = 450;


will result in:

iID = 0;
iX = 100;
iRestoredX = 0;
iY = 100;
iRestoredY = garbage;
iWidth = 800;
iRestoredWidth = 100;
iHeight = 450;
iRestoredHeight = 100;
irreversible
irreversible
Bumping this as I've gone to great lengths to test various scenarios and possible reasons (including making sure none of my dependencies include a class with the same name) and so far the result I'm getting is always exactly the same: this one class, even when initialized at the very top of the program, exhibits erratic member values already at the top of the constructor, right after they've been initialized. Posting the entire code here would be torture, but the best I can tell is that it's no different from any other regular class (no inheritance, no templates, etc).

I really don't know where to keep looking or how to start thinking at this point.
Kovee
Kovee
I'm not sure if it's the cause of your problem, but you are using the old WNDCLASS with the newer CreateWindowEx function. So you might try using WNDCLASSEX with CreateWindowEx or WNDCLASS with CreateWindow. Also check how you register your class. It should be RegisterClass for WNDCLASS and RegisterClassEx for WNDCLASSEX.
ApochPiQ
ApochPiQ
In addition to Kovee's observation, make sure you're not debugging a release build, and try doing a clean/rebuild to see if that helps.


Failing that... best I can suggest is to strip this down bit by bit until you get a reproducible minimal example, and post that for examination, even if it's a bit long.
irreversible
irreversible
Thanks for the suggestions, guys - I synced the Ex and non-Ex calls (not sure why I hadn't done that before) and I've done about 4 clean builds (including a manual clean) with no success. I'm creating a minimal test project now to try and narrow down the problem.

One thing I'm holding suspect - based on the nature of the problem - is actually the compiler or some conflicting build flags. I know I've used the same class name before as well, but I've made damn sure no deprecated headers are included and no intermediate files have survived a project clean; nevertheless, it'd be a mess, but if I can't reproduce the bug, I'll try renaming the class itself.
iMalc
iMalc
I have seen this kind of thing before, usually in release build, but not always.
What you may be seeing is not a bug with the generated code and the code itself may be fine. It is probably the debugger just being confused about the actual locations of everything.
One possible reason is the symbol files are not being regenerated upon each build, and out of date ones are being used. For example you may have changed the project settings to no longer generate them, but there are still pdb files in the directory, which the debugger uses. You may have removed the cleaning of the pdb files from the clean build settings for them to hang around, or something.

Have a look through your project settings and see what differs from the defaults, and delete any pdb files that are there.

Another way this can probably occur is if the pdb file is locked thus and can't be updated or deleted, but the debugger is still able to read it. I'm sure that I've had this happen when there were two copies of mspdbsrv.exe running.
You haven't been using multiple version of MSVC have you?

Lastly, a reboot wouldn't hurt.
irreversible
irreversible
All valid notes, iMalc! I've thought of most of these (eg I've done a manual clean to make sure everything gets regenerated) and I've restarted the OS. After rearranging some code I've managed to get the WinAPI portion of my code running, but now I'm faced with the same problem discussed here: ChoosePixelFormat() and SetPixelFormat() (well, if I cheat my way past the former I get to the latter) are crashing.

Stepping through code, it would appear my window base class initializes just fine as standalone, but when used as the base class for a GL window, the same symptoms appear as described in the original post. Since testing the GL window in a separate project works just fine then, to me, this reeks of a heap corruption. Good luck to me trying to find that in 80 files of code.

Blah - this sucks. I've spent close to a day on this madness.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.