Get Bogus Value When Execute Break Point in a Variable

Get bogus value when execute break point in a variable

Your breakpoint is on the finalScore = line, it means that the program is stopped before this value has been computed.

It should show no value instead of a bogus value, probably, but this is not something that you have to worry about: set your breakpoint one line later and your finalScore will have a proper value.

Can I set a breakpoint when variable is getting a specific value in .NET?

It is certainly possible to set a condition like a variable receiving a certain value. This is known as a breakpoint condition. To create one, do the following.

• Set a break point at the point the variable changes
• Right click on the break point and select "Condition"
• Type in the conditional like "theNewValue == 42"

Now the breakpoint will only hit when your conditional evaluates to true.

The second item you asked for, breaking when a variable's value changes for any reason, is known as a data breakpoint. These are only available for C++ code. It's not an option in C#, VB.NET or any other managed language.

How get a breakpoint on variable write in Visual Studio?

This is referred to as a Data Breakpoint in Visual Studio. To create one you'll need the address of the variable in question (just add &variableName) to the watch or immediate window. Then do the following

1. Debug -> New Breakpoint -> New Data Breakpoint
2. Enter the address in and size of the value in bytes

Note: This is only supported for C++ applications. Managed languages don't support data break points.

Set breakpoint on variable value change

In my experience you can achieve this with a "memory breakpoint" or "memory watch point". For example gdb does it like this: Can I set a breakpoint on 'memory access' in GDB?

As far as I've seen with write watchpoints, the break actually triggers when a is written to, regardless of whether the new value is equal to the old value. So if by "changed" you really mean "changed" then there are fewer examples out there. Possibly even none, I'm not sure, although I don't suppose it would be technically difficult to implement change-only watchpoints, assuming that you were implementing write watchpoints.

For some languages it makes a difference what kind of variable a is. For example, in C or C++ variables can be "lifted" into registers when optimization is enabled, in which case hardware memory watchpoints on the address of the variable will not necessarily catch every change.

There's also a limitation with variables on the stack, that if your function exits but the watchpoint is still set, then it could catch access to the same address, now in use for a different variable in a different function. If your function is called again later (or recursively), it's not necessarily starting from the same stack position, and if not then your watchpoint would fail to catch access to the "same" variable at a different location.

"Stop when a particular condition is true at a particular line of code" is in my experience called a "conditional breakpoint". It generally uses a different mechanism --
the debugger will most likely put a breakpoint instruction at that line of code. Each time it triggers the debugger will check the condition and continue execution if it's false.

Can I find out the return value before returning while debugging in Visual Studio?

Not that I know of. Note that if you do add a variable, it will get removed by the compiler in release builds anyway...

Update:
This functionality has been added to VS2013.
You can see the return values in the autos windows or use $ReturnValue in the watch/immediate window.

The value can only be seen directly after returning from the function, thus the easiest way to access it is by putting a breakpoint on the function call and step over (F10) the call.

---

Update for VS2015: boo! unfortunately, it doesn't appear to be in VS2015 (devenv v14)

Update for VS2017: it's back. (devenv v15)

Why would the value of a variable change after hitting a breakpoint?

Do you happen to have any get {}s with side affects? It's possible that while observing the state of the object, you've change the state of the object.

For example :

class A {
    int one = 0;

    int two { 
        get { 
            one = 1; 
            return 2; 
        } 
    }
}

Now when you assert A.one == 1, it fails. If you look at it, you'll see that two == 2 and one == 1. When you hit retry again, the assertion passes because you've change A.one.

EDIT :

Seeing your code, DateTime.Now changes everytime you call it. You don't think that could be it?

Debugging in Eclipse: Variable Snapshot Without Breakpoint

You can add a conditional breakpoint that returns false. The code in the condition will be evaluated, and then you return false to indicate to the debugger that you do not want to stop execution.

Right click on breakpoint properties,
Check "Conditional"
In the text field, enter the code you want to run (e.g. print x). Make sure the last statement in the condition is "return false"

Here is my code:

public static void main(String[] args) {
        String x  = " Some value"; 
        String y  = "a value"; //breakpoint here
        System.out.println("Hello World!");
    }

Say I want to print the value of x just after it is declared.
Set a breakpoint where indicated in the code,
Add a condition:

System.out.println("Value of x: " + x);
return false;

Output:

Value of x: Some Value
Hello World!

Break when a value changes using the Visual Studio debugger

In the Visual Studio 2005 menu:

Debug -> New Breakpoint -> New Data Breakpoint

Enter:

&myVariable

---

Related Topics