Strange values during debugging ... HELP!

Started by
10 comments, last by Talib 18 years, 9 months ago
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.
Try, try and fucking try again.
Advertisement
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
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.
Try, try and fucking try again.
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?
This is a single-threaded application, right?
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.
Try, try and fucking try again.
Oh yeah, and is single-threaded.
Try, try and fucking try again.
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.
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.
I love programming
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???
Try, try and fucking try again.

This topic is closed to new replies.

Advertisement