Sign in to follow this  
Talib

Strange values during debugging ... HELP!

Recommended Posts

Talib    170
This one function I have written has been giving me so much trouble and I am unable to determine the cause of the errors. Can someone see if they can spot the trouble. It is not to important as to what the code code does but what the values are during debugging. Here is the step through with images: This firs image is the code ... sorry for the pic, anyway i am making use of a lot of pointers and my own custom linked list. This shows the value of the "this" pointer, which is currently fine This image shows the value of cSelectedCard, which is also currently fine Now step one instruction further, and looking at cSelectedCard, everything still seems fine. Another step, everything still fine. Another step, still fine. Another step and everything is still fine and NextCard should be 0x00000000. Thus skipping everthing in the if statement. Now this is where everything falls apart, suddenly TempCard gets a new value out of nowhere! NextCard is not 0x00000000 anymore! And looking at the this pointer, it suddenly also changes for no apparent reason. I cannot explain any of this, please help me, I have no answers.

Share this post


Link to post
Share on other sites
Illco    928
At first sight it indeed seems strange. Have you tried to rebuild all from scratch? Sometimes the debug symbols get corrupted and you might get strange results. Often times rebuilding all fixes these strange issues.

It might also be that something got corrupted elsewhere, usually by faulty memory allocation or deallocation.

Greetz,

Illco

Share this post


Link to post
Share on other sites
Talib    170
Thanks for replying, I have tried a rebuild. Now the weirdest thins if I comment out the part that gets skipped over because of NextCard being 0x00000000 and recompile it works fine ... things just gets stranger.

Share this post


Link to post
Share on other sites
ajas95    767
Are you trying to debug a release build? I've seen behavior like this in release builds, where something like TempCard might not even be allocated on the stack... it might just be kept in a register the whole function, and so the debugger has to follow it through the register. But then the compiler decides it doesn't need the variable anymore, and so starts using the register for something else... which confuses the debugger into thinking the variable is now the value in the register which is totally bogus.

So while the debugger might get confused, I've never seen the compiler actually generate incorrect code. So are you debugging a debug build? Have you tried looking at the disassembly? Does your program actually crash here?

Share this post


Link to post
Share on other sites
Talib    170
It is definately a Debug build (although I tried debugging it in release mode, accidentally, last night). It was definately in DEBUG this morning.

Anyway, after commenting out the part that gets skipped and doing a rebuild ... again (2nd time this morning). It has decided to work. Thanks anyway for all the help.

Share this post


Link to post
Share on other sites
MaulingMonkey    1730
Well this wouldn't be the first time a debugger felt like acting funky. Fact is, my very first topic on these forums (some ~1600 posts and 2+ years ago) had similar issues, with Borland's C++ Builder's Debugger lying about the contents of memory.

At first 0xCCCCCCCC jumped out at me as a fill pattern - it probably is, but it's not one of the usual Win32 Debug CRT patterns.

If I had to guess, I'd say that the debugger is confused by the assignment to a member of itself. Try breaking apart the code:

TempTempCard = TempCard->NextCard;
TempCard = TempTempCard;

And step through that to see if the results are at all different.

Share this post


Link to post
Share on other sites
th3matr1x    100
Hi m8.
I had also some problems with the ms debugger, when working with lots of pointers. It seems that they haven't worked out that thing.
So don't trust that values so much when you work with it.

In your code i have a couple of suggestions, maybe it would help you:

1. at the first line you allocate Tempcard to this.... which is fine, but
why do u use the next line this->cSelectedCard?? (Tempcard would do it fine, speed optimization )

2. at one stage you have Tempcard=Tempcard->NextCard() right?
at that stage your this->cSelectedcard will be also Tempcard->NextCard so basically you lost your original this->cSelectedCard pointer. watch out!!!
I'm not sure what do u really want to do with it.

3. then again in another line Tempcard=this->cSelectedCard !!!!!!! which is basically useless.

4. It's not safe to work on the event onMousemove with a loop without checking if it's not still looping.

so here is my suggestion: actually there are lots of things to work around your problem.
the easiest is to get a copy of your this->cSelectedCard and work with it.
cSelectedCard= new ..... whatever it is
memcopy this->cSelectedCard to Tempcard
a problem may accure with the size of the memory to copy (could be easily worked around if you would put an index counting your cards )
and of course free the copyied memory at the end.

Or just wait till MS will write a debugger that would really work :)

I hope it would help you.

Share this post


Link to post
Share on other sites
Talib    170
Quote:
Original post by th3matr1x
...1. at the first line you allocate Tempcard to this.... which is fine, but
why do u use the next line this->cSelectedCard?? (Tempcard would do it fine, speed optimization )


Yeah, also saw that after I posted, and fixed it, thanks

Quote:

2. at one stage you have Tempcard=Tempcard->NextCard() right?
at that stage your this->cSelectedcard will be also Tempcard->NextCard so basically you lost your original this->cSelectedCard pointer. watch out!!!
I'm not sure what do u really want to do with it.


NextCard() is not a function it is a pointer to the nextcard, cSelectedCard remains the same until I change it.

Quote:

3. then again in another line Tempcard=this->cSelectedCard !!!!!!! which is basically useless.

It is there for the last part that is commented out (still to be implemented)

Quote:

4. It's not safe to work on the event onMousemove with a loop without checking if it's not still looping.

huh???

Share this post


Link to post
Share on other sites
th3matr1x    100
your right with the next thingy, I waked up a couple of minutes ago, when i saw your code oO.

but while moving your mouse, you calculate the hole thing again.
Why not check if the mouse move have started, then make your calculation once.

I mean assume that the loop will take longer the milliseconds ( 5 sec as an example ), and you are moving the mouse a lot quicker, what would happen?

Share this post


Link to post
Share on other sites
Talib    170
I see what your getting to, luckily, this routine is quick and doesn't slow down (that I can see). Will see if I want to rewrite it, prolly will, stuff like that keeps nagging me until I fix it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this