The debugger was currently set to this line...
but then
Why?
There are a number of minor bugs in the F# breakpoint location code (even in DEBUG). A couple of workarounds are: set the breakpoint on a different line above and step down into the code, or change the code and add "ignore()" on its own line, and put a breakpoint there.
I suspect that let x = debug is being removed by the compiler (as x is not otherwise used).
This kind of thing is common in a release build where significant rearrangement of code by the optimiser happens, but depending on the compiler this can also happen in a non-optimising build.
Why not set the break point on the previous expression?
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.
We have a strange error with our debuggers when running the debugger on a phone in release mode. Whether we are using gdb or lldb with xcode 4.3.3, the code will land on breakpoints even though the code's PC is not really pointing at that spot.
Example fake code:
if (true) {
// set breakpoint-A here
} else {
// set breakpoint-B here
}
// set another breakpoint-C here.
It will land in breakpoint-B and then jump to breakpoint-A.
Is the cause because we are in "release" mode and it's optimizing?
Thanks!
Yes, there are three things going on here: When you build in release mode, the compiler is doing optimized code generation. The compiler may change the order that source lines are compiled into the program (as long as it doesn't change the meaning of the code), instructions between different source lines may be intermixed or rearranged, and finally there can be problems with the line table that the compiler emits.
Imagine two source lines, each which turn in to 8 assembly language instructions. The compiler may rearrange these 16 instructions (as long as it doesn't change the results of them) to keep the CPU(s) running most efficiently. But in this situation, what instruction should the compiler say is equivalent to line 1? and what instruction should the compiler say is equivalent to line 2?
With optimized code debugging, if you're debugging at a source code level, you have to live with the reality that the "currently executing source line" is going to bounce around a lot while you step through your program. Variables that seem to be in scope will appear and disappear at nonobvious times. The compiler's ways are tricky and hard to understand. You need to debug with the assembly language code in front of you (or a source + assembly display) to really follow what's happening.
There are improvements that compilers and debuggers can make to improve optimized code source-level debugging but it will probably always be a little hard to follow.
Xcode also tends to jump from any return statement in a method to the first return statement in that method. (Xcode 4.3.3 still does it. I am not sure about 4.5 yet.)
Just ignore that last highlighted 'return' statment.
Does anyone know what's the difference between using breakpoints and calling DebugBreak() func. for example in windows platforms ?
The obvious difference is that putting a breakpoint in is an interactive process - it has to be done manually (by each developer who wants to break at a certain point). This is flexible, but manual.
On the other hand, as DebugBreak is programmatic, it means that it affects all developers who run through that code (which may be appropriate if you always want developers to stop at that point as it means something's about to go wrong, for example) - but you won't be able to add breakpoints as flexibly while the code is executing.
Use each technique in its place - personally I don't use programmatically-forced break points very often at all.
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.
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.