On 4/7/2012 1:52 PM, Orchid Win7 v1 wrote:
> I almost feel like I'm going mad. I'm trying to use the NetBeans
> debugger, and... well... it doesn't appear to /work/.
>
> 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.

And, yeah, its a damn pain in the ass that this happens, but sort of 
understandable (especially when its in a library, or the like, where you 
might have 3-4 instances running in memory, so you actually could, in 
principle, have 3-4 different copies of the same variable, all of them 
changing independently). What might be nice is a way to identify which 
thing the variable really belongs to, like contextual highlighting 
**if** its the one local to what you are looking at. Or, if you want to 
live dangerous, and be more confused, you could just have it track which 
ever one "is" being looked at... I think the "highlight the one you are 
currently looking at" version, would be better, since you can tell what 
you are actually dealing with, and not confuse the current one with one 
that belongs to something else, or some other instance. A combination 
could be helpful in some cases too, but then you kind of need to have 
some way to tell which of these is the "local" one:

int id 234
int id 10
int id 135435

Other than that one happens to be changing. And, there may be cases 
where you do need to see what all of them at doing, even with the same 
name, so:

main:  int id 234
sub1:  int id 10
print: int id 135435

Its just, doing that isn't something some debuggers just don't handle 
right (in at least one case, setting the watch on it worked, the first 
pass through, but the second time the function was called, it was no 
longer tracking the same variable. Why? Because the original variable 
didn't exist, just a new one, which happened to have the same name, and 
so it couldn't "track" changes to something that wasn't there any more.

Yeah, doesn't make a lot of sense, from a debugging standpoint, to me 
either, but that is what the bloody thing was doing, tracking the "last 
value" the original one had, even thought it was gone, and I wanted to 
see what the new copy was doing. I don't remember how/if I got around 
the bloody problem at the time.

Post a reply to this message