>> I'm single-stepping through the code, and half the time the local
>> variables window doesn't even remotely correspond to the code I'm
>> actually looking at. I step over a line that says id++, and the id field
>> remains stubbornly fixed at its previous value. Even though I just
>> god-damn /watched/ the increment instruction execute! WTF?!

> Often a result of the "id" being tracked having been from "someplace
> else", like a different function, and thus the "local" copy is changing,
> or the copy within *this instance of the function call*, but not the one
> that is actually being tracked (which was the last time it was called,
> or from a different function or... who the hell knows). Basically,
> tracking is context insensitive, so you are not tracking which ever
> version of the variable you are currently stepping through, as expected,
> you are tracking one from a different context.

Thing is, most of the time when you jump to another function, the local 
variables display updates to reflect that you're now in a different 
scope. But, about 30% of the time, /it doesn't update/. So you're now 
looking at a completely irrelevant bunch of data while single-stepping 
your code.

I haven't seen any other debugger fail in this way. I've seen debuggers 
where you can't /see/ all the local variables, only the once you've 
configured to "watch". But I haven't seen a debugger where the watched 
variables don't actually frigging update at random. I can only imagine 
it's a bug. A bug... in the debugger. Now that's meta.

Post a reply to this message