backward debugging in Visual Studio??

Hello everyone,


Suppose a program looks like,

--------------------
code block 1;

if (condition == true)
{
code block 2;
}
--------------------

I want to see the state of block 1 (variable values) if condition is true. So I am wondering whether Visual Studio supports backward debugging, if it supports, I could set a breakpoint at the beginning of code block 2, and if it is executed, I could run *back* to the beginning of code block 1 to execute code block 1 again see the detailed running process of code block 1.


thanks in advance,
George

This should be moved someplace else, as it isn't C specific. It's compiler, or rather, IDE specific.

1 - Install the MSDN.
2 - Press F1.
3 - RTFMSDN!


Quzah.

The way I handle this is to set a stop on the variable. In the first code block, whenever that variable was changed to true (in your case), the program would instantly stop. Long before you got into the second code block.

Very handy, and certainly supported by nearly all IDE's.

Adak

You can also use a conditional breakpoint.

Quote:

---

Originally Posted by quzah

This should be moved someplace else, as it isn't C specific. It's compiler, or rather, IDE specific.

1 - Install the MSDN.
2 - Press F1.
3 - RTFMSDN!


Quzah.

---

What is RTFMSDN??


regards,
George

Thank you anonytmouse!

Quote:

---

Originally Posted by anonytmouse

You can also use a conditional breakpoint.

---

I have tried ... But in my situation, it is hard to know the condition before an error occurs ... means the condisiton is not predictable and there is not a fixed a rule for defining conditions. The only point where I can find errors is, the execution of code block 2.

In more details, I want to monitor the original values, which will incur the error. For example, code block 1 will be executed a lot of times and code block 2 will only be executed when there are some errors. I want to set a breakpoint to the beginning of code block 2 and find the states of variables in code block 1 when there are errors. I can not set a break point to the beginning of code block 1 since it will be executed a lot of times even if there are no errors ...


regards,
George

Thank you Adak!

Quote:

---

Originally Posted by Adak

The way I handle this is to set a stop on the variable. In the first code block, whenever that variable was changed to true (in your case), the program would instantly stop. Long before you got into the second code block.

Very handy, and certainly supported by nearly all IDE's.

Adak

---

I have tried ... But in my situation, the condition bool variable is a function in my situation (not a simple variable), and it is hard to know the condition which will incur an error, before an error occurs ... means the condisiton is not predictable and there is not a fixed a rule for defining conditions. The only point where I can find errors is, the execution of code block 2.

In more details, I want to monitor the original values, which will incur the error. For example, code block 1 will be executed a lot of times and code block 2 will only be executed when there are some errors. I want to set a breakpoint to the beginning of code block 2 and find the states of variables in code block 1 when there are errors. I can not set a break point to the beginning of code block 1 since it will be executed a lot of times even if there are no errors ...


regards,
George

I'm a little confused as to why you are having problems with this.
The code snippet you provide seems to indicate that code block 1 is within scope of code block 2. Is this the case?

Because if it is you can simply place your breakpoint at the beginning of code block 2 and use the debugger to get information on the names in code block 1. All you have to do once the program breaks is to set watches for each name you want to check the value of.

Another thing I have prolem understanding is why you say the condition predicate is unpredictable. I guess it's best if you provide us with real life code. Regardless, you can set conditional breakpoints where the condition part of the breakpoint is a function.

Another option, which I'm almost sure MSVC++ also supports is offset breakpoints. You can set a breakpoint at the beginning of code block 2 and have it offset X lines from where it stopped. In this case you would have it offset upwards in the code, probably to the beginning of code block 1. However, there's a catch. You can only offset within the same stack frame.

As you can see there's at least 3 options. But if code block 1 is not within scope of code block 2, then you need to provide us the code so that we can study the solution better. However, almost always the solution to that is to examine the call stack and then backtrace accordingly.

Thank you Mario,

Quote:

---

Originally Posted by Mario F.

I'm a little confused as to why you are having problems with this.
The code snippet you provide seems to indicate that code block 1 is within scope of code block 2. Is this the case?

Because if it is you can simply place your breakpoint at the beginning of code block 2 and use the debugger to get information on the names in code block 1. All you have to do once the program breaks is to set watches for each name you want to check the value of.

Another thing I have prolem understanding is why you say the condition predicate is unpredictable. I guess it's best if you provide us with real life code. Regardless, you can set conditional breakpoints where the condition part of the breakpoint is a function.

Another option, which I'm almost sure MSVC++ also supports is offset breakpoints. You can set a breakpoint at the beginning of code block 2 and have it offset X lines from where it stopped. In this case you would have it offset upwards in the code, probably to the beginning of code block 1. However, there's a catch. You can only offset within the same stack frame.

As you can see there's at least 3 options. But if code block 1 is not within scope of code block 2, then you need to provide us the code so that we can study the solution better. However, almost always the solution to that is to examine the call stack and then backtrace accordingly.

---

The code is too long and application dependent. I have simplified it. Here it is,

// code block 1 begins
set variable A to some value;
some operations on variable A;
set variable A to some other value;
some operations on variable A;
set variable A to some other value;
some operations on variable A;

// code block 2 begins
if (true == condition)
{
error checking ...
}

In this scenario, I am interested in variable A and since it is changed several times, so even if I catch (by setting a break point at the beginning of code block 2) the error condition in code block 2, it is hard to know the detailed information of the original value and the values of variable A changed each time.


regards,
George

You still don't provide enough information, george.

what exactly is code block 1? just a set of operations in scope of code blocks 2? In other words, things like "set variable A to some other value;" and "some operations on variable A;" are happening inside functions? Or instead they are just a string of expressions within the same function where the error checking is happening?

If they are happening inside functions, backtrace in the call stack. Check your compiler manual to learn how to. If not, you can use breakpoint offsets. Also check your compiler manual on how to.

For all cases, you can set the breakpoint at the beginning of code block 2.

Thank you Mario!

Quote:

---

Originally Posted by Mario F.

You still don't provide enough information, george.

what exactly is code block 1? just a set of operations in scope of code blocks 2? In other words, things like "set variable A to some other value;" and "some operations on variable A;" are happening inside functions? Or instead they are just a string of expressions within the same function where the error checking is happening?

If they are happening inside functions, backtrace in the call stack. Check your compiler manual to learn how to. If not, you can use breakpoint offsets. Also check your compiler manual on how to.

For all cases, you can set the breakpoint at the beginning of code block 2.

---

1. Backtrace means call stack?

2. Breakpoint offsets is a good idea, does Visual Studio 2003 supports it?


regards,
George

Quote:

---

1. Backtrace means call stack?

---

Yes.

Also see http://www.cprogramming.com/debuggers.html and maybe try googling for it: http://www.google.ca/search?hl=en&q=...G=Search&meta=

Code:

---

set variable A to some value;
some operations on variable A;
set variable A to some other value;
some operations on variable A;
set variable A to some other value;
some operations on variable A;

---

Maybe avoid over-enthusiastic variable re-use and have

Code:

---

set variable A to some value;
some operations on variable A;
set variable B to some other value;
some operations on variable B;
set variable C to some other value;
some operations on variable C;

---

or maybe check for errors between operations.

Or maybe save the 3 separate interesting values of A in other variables so they're available when you hit the breakpoint.