Printable View
I've got a (lengthy) program, and when I run it, some variables get some really bogus values for some reason. When I debug it to find the cause of it, the values are fine, making it difficult to track down the problem.
So, my question is, what could cause this? Obviously the debugger does something differently. I read somewhere that the debugger gives values to uninitialized variables, though I don't think this is my particular problem.
So, any ideas?
Cheers.
BTW, I'm using MSVS '08.
I'd suggest you post your complete code, or at least make a copy of it and strip it down as much as possible, while still reproducing the issue. Also, when you run it how do you know the variables have "bogus" values? Are you using them without initializing them? Either that or some pointer arithmetic is my guess as to where the problem lies.Quote:
I've got a (lengthy) program, and when I run it, some variables get some really bogus values for some reason
Yes, you're correct that debuggers generally do things differently. What it does depends entirely on what compiler/debugger you're using, I imagine your using VC++.
Again, I'd suggest to post the code (preferably a "small" version of it). Also highlight in the code the "problem" areas, as well as any other details, like input, output, etc. Without seeing any code we can only guess what the problem is (i.e. using without initializing, etc).
After looking for a bit, it does seem to be a problem with pointers. To sum up the code a bit, I am accessing a member of a class. When I access it directly, it works fine, but when I use a pointer to it, it doesn't work, even though the pointer itself appears to be legit. Here's a small example:
Code:class FOO
{
public:
int a;
};
FOO foo;
foo.a = 12;
int *bar = &foo.a;
foo.a == 12; // this is true
*bar == 12; // this is false
How do you know what they are evaluated to? Do something like this, for bothIf its still acting weird, maybe changeCode:if ( foo.a == 12 )
cout << "true";
else
cout << "false";
toCode:int *bar = &foo.a;
but I think it should be OK as is.Code:int *bar = &(foo.a);
Yes, that is sort of how I am doing it, though through a message box. And it is obvious things are going wrong because the program starts doing weird things.Quote:
Originally Posted by nadroj
That didn't do it either.Quote:
Originally Posted by nadroj
Well if that isn't ambiguous.... :)Quote:
And it is obvious things are going wrong because the program starts doing weird things.
I tried the code above, after syntactically fixing it, and adding the print statements I mentioned above and I get the expected output (two "true"s printed). Not sure what else to say. Maybe try creating an entirely new "project" in your IDE, and copy/paste the above small program with basic "cout" print statements and see if that gives expected output.
Hmm... I guess I'll just keep searching for the problem then. Thanks for your help, though.
Maybe post your exact, complete "small" version that reproduces the problem. The one that "does weird things at startup", etc., and I can try to run it.
The problem is, I've got 1000s of lines of code and this particular variable is used a number of times through out it (I doubt I could find them all).
Working on debug but not release mode suggests that you have some undefined behavior.
You need to prune your program untill the problem either goes away, and you can attribute it to the last remove; or until you have a minimalistic program that encounters the problem, which you can post here.
From our discussion above it was my understanding that you wrote a "small" ("small" being relative) program that reproduces the problem. And that you ran that, and still got the "weird behaviour". If you're still running a program with thousands of lines of code, there's, of course, more than a thousand places where the logic error could be.
Working from your post above (http://cboard.cprogramming.com/cplus...tml#post928265) modify that to be an actual program, run it (not debug it!) and tell us the output, i.e. does it print that they are equal or not equal. Of course post all of that complete, small program that you run.
No, sorry, that small code a gave you doesn't produce the error (I just tested it), rather, it is sort of what it going on in my actual program. It just seems weird that it is pointing to the same place (I assume), yet the data is different.
I don't think we can do anything if we don't have some code that we are all discussing, which of course reproduces the problem. Maybe turn your compiler warning level up as high/strict as possible and try to fix every single warning.
Ahh, I figured it out. I changed (or forgot to change) the pointer at one point in the code. But now I'm confused as to why it DID work under debug mode. All well, at least it's working now. Thanks for your help.
If your code works in debug mode but not in release mode, my first guess would be stack corruption, because in debug mode, VS adds 4 extra bytes of padding before and after your variables; so if you write a few bytes past the end of an array it won`t corrupt other variables the way it does in release mode.
Check for stack corruption by opening the Memory viewer and step through your program line by line to see if any of the padding characters get overwritten (you should have 0xCDCDCDCD before and after your arrays).
cpjust, can you vouch for the VS development team and summarize why they do this? Or is this common in other debuggers? To me it seems like they're saying "If you make mistakes when it doesn't matter (debug build), its OK we're protecting you. If you make mistakes when it does matter (release build) you're screwed."
Of course when releasing software, our job is to sufficiently test it, and not rely on a compiler/debugger saying it works or not. But isn't, by the debug mode being less strict, just adding to the potential for errors slipping through?
EDIT: I just wanted to clarify I'm not anti-Microsoft (though not necessarily pro-Microsoft), so it isn't about just trying to point them out. VS is an unbelievably good piece of software.
Then how would that affect pointers to memory on the heap? Not sure how bad pointers to addresses on the heap could cause stack corruption. And if the program causes stack corruption a dialog box will be displayed stating as much when the program is run.Quote:
VS adds 4 extra bytes of padding before and after your variables; so if you write a few bytes past the end of an array it won`t corrupt other variables the way it does in release mode.
You can get away with more in debug mode as well even with allocations on the heap b/c the debug CRT puts a lot more information before each block - not sure if it puts any information following the memory block. But this means the prior block could overwrite quite a bit of the next block's information without causing problems...that is until the next block is cleaned up at which point b/c the information in the debug block header is corrupt the heap will become corrupted. This would most likely happen when the block with corrupted debug header information was deleted.
I believe they do that to make it easier to detect stack corruption, since you can then look at the memory and see if those 0xCDCDCDCD bytes change. But yes, it can make bugs less apparent if you don't know what you're looking for.Quote:
Originally Posted by nadroj
I never said it did affect heap memory. I have no idea what nadroj's program is doing, so I thought he might have some arrays that were being overflowed.Quote:
Originally Posted by Bubba
I have no clue what my program is doing either... I never wrote one! You probably meant yaya's.Quote:
Originally Posted by cpjust