So I'm working on a project where I have really long for loops and I'm usually encountering problems when getting close to the end of the loop, but it's pretty much impossible to get there manually by stepping into the loop millions of time. I know I could just change the counter variable, but in this case it would not work because the side-effects of each iteration wont happen. Is there a way to make a breakpoint stop on a place after 999999998 iterations?
I'm using Visual Studio Ultimate 2010
put a breakpoint,
right click on it,
choose condition
set
i == 999999998 //if your loop looks like for (var i == 0;....
I am just pasting an image to visualize Raphaël Althaus's Answer
As Raphaël says, you can set a condition on a breakpoint. However, if this happens in a tight loop the overhead of the condition can be quite significant. I've found that doing the check in the code and calling Debugger.Break works much better in that case.
Related
I'm not sure how to really put my question into words so let me try to explain it with an example:
Let's say my program runs into some weird behavior at a specific action. I already find some code which is the cause of this weird behavior. When disabling this sequence I don't run into this behavior. Unfortunately, I need this code because something else is not working then.
So, what I gonna do next is figuring out why something is going different when that code excerpt is active.
In order to better understand what's going on I sometimes want to run the whole action including the 'bad code' and sometimes without. Then I can compare the outcome, for example what happens in the UI or what my function returns.
The first approach which comes to my mind is to run my program with the code enabled, do whatever I want, then stop my program, comment out the code, recompile and run again. Um... that sounds dumb. Especially if I then again need to turn on that code to see another time the other behavior, and then again turn off, and on, and off and so on.
It's not an option for me to use breakpoints and influence the statement order or to modify values so that I run or not run into if-statements, for-loops etc. Two examples:
I debug a timing critical behavior and when I halt the program the timing changes significantly. Thus, the first breakpoint I can set must be at the end of the action. 1
I expect a tooltip or other window to appear which is 'suppressed' when focus is given to VS. Thus, I cannot use any breakpoints at all. Neither in the beginning nor at the end of the action.1
Is there any technique in Visual Studio 2012 which allows me to mark this code to be optional and I can decide whether or not I want to run this code sequence before I execute the action? I think of something like if(true|false) on a higher level.
I'm not looking for a solution where I need to re-run my program several times. In that case I could still doing the simple approach of simply commenting out the code with #if false.
1 Note that I, of course, may set a breakpoint when I need to look into a specific variable at a certain position (if I haven't written the value into output) but will turn off breakpoints again to run the whole action in one go.
In the Visual Studio debugger you can set a breakpoint right in front of your "code in question". When the code stops at that point, you can elect to let it continue or you can right-click on any other line and select Set Next Statement.
It's kind of a weird option, but I've come to appreciate it.
The only option I can think of is to add something to your UI that only appears when debugging, giving you the option to include/exclude the operations in question.
While you're at it, you might want to enable resetting the application to a "known state" from the UI as well.
I think of something like if(true|false) on a higher level.
Why "on a higher level"? Why not use exactly this?
You want a piece of code sometimes executed, sometimes not, and the switch should be changed at run time, not at compile time - this obviously leads to
if(condition)
{
// code in stake
}
The catch here is what kind of condition you will use - maybe a variable you set to true in the release version of your code, and to false sometimes in your debug version. Maybe the value is taken from a configuration file, maybe from an environment variable, maybe calculated by some kind of logic in your program, whatever and whenever you like.
EDIT: you could also introduce a boolean variable in your code for condition, initialize it to true by default and change its value using the debugger whenever you like.
Preprocessor Directives might be what you're after. They're bits of code for the compiler to execute, identifiable by starting with a # character (and stylistically, by default they don't follow the indent pattern of your code, instead always residing firmly at the left-hand edge of the editor):
#define INCLUDE_DODGY_CODE
public void MyMethodWithDodgyBits() {
#if INCLUDE_DODGY_CODE
myDodgyMethod();
#endif
myOkMethod();
}
In this case, if #define INCLUDE_DODGY_CODE was included, the myDodgyMethod() call will be compiled into your program. Otherwise, the call will be skipped by the compiler and will simply not exist in your binary.
There are a couple of options for debugging as you ask.
Visual Studio has a number of options to directly navigate through code. You can use the Set Next Statement feature to move directly to a particular statement. You can also directly edit values through the Immediate Window the QuickWatch and the tooltip that hovers over variables while debugging.
Visual Studio also has the ability to playback the execution history. Take a look at IntelliTrace to get started. It can be helpful when you have multiple areas of concern that are interacting and generating the error condition.
You can also wrap your sections of code within conditional blocks, and set the conditional variables as appropriate. That could be while you're debugging, or you could pass parameters in through a configuration file. Using conditional checks may be easier than manually stepping through code if there are a number of statements you wish to exclude.
It sometimes depends on the version of VS and the language, but you can happily edit the code (to comment it out, or wrap it in a big #ifdef 0) then press alt+F10 and the compiler will recompile, relink and continue execution as if you'd never fiddled with it.
But while that works beautifully in VC++ (since VS v6 IIRC), C# can have issues - I find (with VS2010) that I cannot edit and continue in this way with functions containing any lambda (mainly linq) statements, and 64-bit code never used to do this too. Still, its worth experimenting with as its really useful sometimes.
I have worked on applications that have optional code used for debugging alone that should not appear in the production environment. This segment of optional code was easiest for us to control using a config file since it didn't require a re-compile to change.
Such a fix might not be the end all be all for your end result, but it might help get through it until a fix is found. If you have multiple optional sections that need to be tested in combination this style of fix could require multiple keys in the config file, which could be a downside and a pain to keep track of.
Your question isn't exactly clear, which is possibly why there are so many answers which you think are invalid. You may want to consider rewording it if no one seems able to answer the question.
With the risk of giving another non-valid answer I'll add some input on how I've dealt with the issue in the past.
The easiest way is to place any optional code within
#if DEBUG
//Optional code here
#endif
That way, when you run in debug mode the code is implemented and when you run in release mode it's not. Switching between the two requires clicking one button.
I've also solved the same problem in a similar way with a simple flag:
bool runOptionalCode = false;
then
if (runOptionalCode)
{
//Place optional code here
}
Again, switching between modes requires changing one word, so is a simple task. You mention this in your question but discount it for reasons that are unclear. As I said, it requires very little effort to switch between the two.
If you need to make changes between the code while it's running the best way is to use a UI item or a keystroke which modifies the flag mentioned in the example above. Depending on your application though this could be more effort than it's worth. In the past I've found that when I have a key listener already implemented as part of the project, having a couple of key strokes decide whether to run my debug (optional) code works best. In an application without key listeners I'd rather stick with one of the previous methods.
I read a description of how intellitrace in VS2010 Ultimate is like going back in time, in the execution of your application.
However, this sounds just like moving the line marker to a previous line (that yellow arrow in the breakpoints margin to the left of the code, when you are stepping through code).
Thanks
From Wikipedia:
Unlike the current debugger, that records only the currently-active stack, IntelliTrace records all events like prior function calls, method parameters, events, exceptions etc. This allows the code execution to be rewound in case a breakpoint wasn't set where the error occurred.
When you move the execution point back you run the same code again, but the variables might have different values. This is because running the code the first time may have changed some variables.
With Intellitrace you should be able to run the same code again with the same values as the first time. I have not tested it though.
The difference is that intellitrace keeps the history of each of those moments that it recorded. So unlike moving the line marker it is showing you the value of all the variables at that point in time. Similar to how a memory dump but for debugging.
It relies heavily on Tracing hence the name. Here is a good explanation of how it works. It's actually pretty cool.
I commonly place into variables values that are only used once after assignment. I do this to make debugging more convenient later, as I'm able to hover the value on the one line where it's later used.
For example, this code doesn't let you hover the value of GetFoo():
return GetFoo();
But this code does:
var foo = GetFoo();
return foo; // your hover-foo is great
This smells very YAGNI-esque, as the functionality of the foo's assignment won't ever be used until someone needs to debug its value, which may never happen. If it weren't for the merely foreseen debugging session, the first code snippet above keeps the code simpler.
How would you write the code to best compromise between simplicity and ease of debugger use?
I don't know about other debuggers, but the integrated Visual Studio debugger will report what was returned from a function in the "Autos" window; once you step over the return statement, the return value shows up as "[function name] returned" with a value of whatever value was returned.
gdb supports the same functionality as well; the "finish" command executes the rest of the current function and prints the return value.
This being a very useful feature, I'd be surprised if most other debuggers didn't support this capability.
As for the more general "problem" of "debugger-only variables," are they really debugger-only? I tend to think that the use of well-named temporary variables can significantly improve code readability as well.
Another possibility is to learn enough assembly programming that you can read the code your compiler generates. With that skill, you can figure out where the value is being held (in a register, in memory) and see the value without having to store it in a variable.
This skill is very useful if you are ever need to debug an optimized executable. The optimizer can generate code that is significantly different from how you wrote it such that symbolic debugging is not helpful.
Another reason why you don't need intermediate variables in the Visual Studio debugger is that you can evaluate the function in the Watch Window and the Immediate window. For the watch window, just simply highlight the statement you want evaluated and drag it into the window.
I'd argue that it's not worth worrying about. Given that there's no runtime overhead in the typical case, go nuts. I think that breaking down complex statements into multiple simple statements usually increases readability.
I would leave out the assignment until it is needed. If you never happen to be in that bit of code, wanting a look at that variable, you haven't cluttered up your code unnecessarily. When you run across the need, put it in (it should be a trivial Extract Variable refactoring). And when you're done with that debugging session, get rid of it (Inline Variable). If you find yourself debugging so much - and so much at that particular point - that you're weary of refactoring back and forth, then think about ways to avoid the need; maybe more unit tests would help.
When I use conditional breakpoint in VS2005 instead of using temporary code to check specific conditions, I noticed it takes more time and the execution speed is decreased!!
Do you know why? and how to resolve this issue?
Exmaple:
int sequence = atoi(m_SequenceNumber.GetAscii());
if( sequence == 392914)//temporary code to check to step into code
{
int x = 0;//I put breakpoint here
}
The previous code will execute faster than if I used conditional breakpoint with ( sequence == 392914)
It is better (if possible) to use a memory watchpoint than a conditional breakpoint. A conditional breakpoint (as others have pointed out) has to run additional code each time the execution pointer goes past that point in order to determine if it would break or not - obviously this takes additional time. A memory watchpoint of a certain type gets to use certain special hardware registers - there is a limit on how many watchpoints you can set that can get accelerated, but if you can use them there is almost no speed penalty.
A memory watchpoint is set using the breakpoint window. You do not set it on a line of code, but rather on an address in memory. This suggests the obvious limitation, it only works for things you can actually take the address of, such as global variables and dynamically allocated areas of memory (using new etc). You are limited in how much memory you are allowed to watch (based on the CPU, I think you probably get more or less special registers allocated).
I'm not actually sitting in front of VS right now, but roughly speaking, you right click in the breakpoints window and choose something like "new data breakpoint". You then enter the address of the memory and the size in bytes. Whenever the value changes your watchpoint will fire. This is particularly useful for figuring out memory corruption issues.
I have run into this problem in the past as well and never really found a way to continue using Conditional Breakpoints within a large loop without affecting performance. I did learn that you could insert some temporary code like this that would not affect performance and would cause VS to break (same behavior as a Conditional Breakpoint).
if ( condition ) Debugger.Break();
Think about how you would implement a conditional breakpoint if you were writing a debugger. The only time the debugger has an opportunity to evaluate the condition is when the breakpoint is hit. So even though the breakpoint is conditional as far as you're concerned, as far as the processor is concerned the breakpoint is being hit everytime the instruction is executed. The debugger gets control and does the following:
determines that the breakpoint is conditional
evaluates the expression
if the expression is false, the debugger continues execution
otherwise, the debugger turns control over to you
So even if you never see the breakpoint hit (because the condition is not met), the debugger may be fielding the breakpoint and evaluating the condition thousands of times a second (or more maybe).
I assume it is because it takes time to execute the condition. It is still a lot faster than manually stepping the necessary number of times tough.
Added temporary code can be optimized (at least a bit) by the compiler.
Conditional breakpoint probably jumps to some visual studio code that will manually retrieve needed information to know whether it actually has to pause or not.
That would somehow explain why it takes more time.
But i am just guessing.
If, like me, you shiver at the site of a While (True) loop, then you too must have thought long and hard about the best way to refactor it away. I've seen several different implementations, none really better than any other, such as the timer & delegate combination.
So what's the best way you've come up with or seen to refactor the dreaded While (True) loop?
Edit: As some comments mentioned, my intent was for this question to be an "infinite loop" refactoring, such as running a Windows style service where the only stop conditions would be OnStop or a fatal exception.
My preference would be
start:
// code goes here
goto start;
This most clearly expresses the intent. Good luck getting it past your coding standards. (Wonder how much karma this is going to cost me).
Do we really need to refactor while(true) loops?
Sometimes it's a coding standard and most of the developers has got used to this structure. If you have to think hard on how to refactor this code, are you sure it's a good idea to refactor it?
Goto used to be a black sheep in coding standards. I've met algorithms where goto made the code much more readable and shorter. Sometimes it doesn't worth to refactor (or better to use goto).
On the other hand you can avoid while(true) most of the time.
What's so dreaded about it? Try finding a common break condition and refactor it to be the head of the loop. If that's not possible – fine.
When I encounter a while(true) loop, that tells me either
the break condition is not easily tested at the top (or bottom) of the loop,
there are multiple break conditions,
or the prior programmer was too lazy to factor the loop properly.
1 and 2 means you might as well stick with while(true). (I use for(;;), but that's a style thing in my opinion.) I'm with another poster, why dread this? I dread tortored loops that jump through hoops to get the loop rolled "properly".
Why refactor? And what is so "dreadful" about this construct? It is widely used, and well understood.
If it ain't broke, don't fix it.
Replace True with the condition you were going to use to break out of the loop.
In the case of a service or background thread, you might use:
volatile bool m_shutdown = false;
void Run()
{
while (!m_shutdown)
{ ... }
}
The "running forever" situation is sometimes part of a larger state machine. Many embedded devices (with run-forever loops) don't really run forever. They often have several operating modes and will sequence among those modes.
When we built heat-pump controllers, there was a power-on-self-test (POST) mode that ran for a little while. Then there was a preliminary environmental gathering mode that ran until we figured out all the zones and thermostats and what-not.
Some engineers claimed that what came next was the "run-forever" loop. It wasn't really that simple. It was actually several operating modes that flipped and flopped. There was heating, and defrosting, and cooling, and idling, and other stuff.
My preference is to treat a "forever" loop as really just one operating mode -- there may be others at some point in the future.
someMode= True
while someMode:
try:
... do stuff ...
except SomeException, e:
log.exception( e )
# will keep running
except OtherException, e:
log.info( "stopping now" )
someMode= False
Under some circumstances, nothing we've seen so far sets someMode to False. But I like to pretend that there'll be a mode change in some future version.
#define ever 1
for (;ever;)
?
Meh, just leave it how it is, while (true) is probably as legible as you're going to get..
errr, to be a refactoring.....
Replace Infinite Loop with Infinite Recursion :-)
well, if you have a language that supports Tail calls....
If you want it to continue indefinitely until a total abortion of program flow, I don't see anything wrong with while (true). I encountered it recently in a .NET data collection service that combined while (true) with thread.sleep to wake up every minute and poll the third-party data service for new reports. I considered refactoring it with a timer and a delegate, but ultimately decided that this was the simplest and easiest-to-read method. 9 times out of 10 it's a clear code smell, but when there's no exit condition, why make things more difficult?
I don't mind it when the infinite loop is contained within a window, and dies with the window.
Think of the Hasselhoff Recursion.
void whiletrue_sim(void)
{
//some code
whiletrue_sim();
}
Warning: Your stack may overflow.