Visual Studio C++ 2013 Debugger Erratic Step Behavior

Question

I'm debugging a c++ application with visual studio c++ 2013 express edition, and my debugger is erratically jumping over lines of code in a certain region of my program. Here is some background info. and the behavior that I'm observing

• Everything is normal until I make a call to make_shared< MyClass >(...)
• Then when the debugger enters my constructor for MyClass, which is empty except for an initializer list, the debugger begins to jump several lines ahead each time I hit "next line"
• The debugger lands on random lines, skipping between different member functions
• Importantly, the debugger stops sometimes on lines that are comments
• My code seems to be running correctly, and if I wait until a few minutes after this make_shared call I mentioned above, I can place my breakpoint and step through the program normally. It seems like that constructor is the only thing not working. The main annoyance is that other breakpoints are being hit because of this erratic behavior, so I can't easily skip over it, if that makes sense.

And here is what I have tried doing to fix this

• I've tried clearing my bin folders, deleting the .exe and .pdb files and whatever else was there
• I've tried completely remaking the project, making a new solution, copying all the .h and .cpp files into the new project, and freshly building and running it. Everything seems to work fine, but whenever I place a certain breakpoint in my code, I find that it's being hit for no reason, and this erratic behavior starts.

I'd be interested in any general advice anyone could give for this situation. I've been working with the same project for a long time and I've never had this problem. I was very surprised when it persisted after I made a completely new project, and I wonder what could be causing it.

edit: Just for reference, there is absolutely nothing fancy in my application at all. I am not including any external libraries other that the standard one. There aren't multiple threads or custom build settings. Everything is very much standard relative to what the default settings are when you make a new, empty, vanilla visual studio project.

Answer 1

The problem can also be caused by mixed line endings. Have a look here . Never mix different line endings in a source file (Linux style: LF '\\n', Mac OS up to verison 9: CR '\\r', Windows: CRLF '\\r\\n'). Be careful when you copy/paste code from somewhere else into your source file.

Go to "Advanced Save Options" in Visual Studio and chooose a the line endings and save the file.

Answer 2

Your information sounds like 1 of 2 issue: synchronization issue between source listing and the debug information or Optimization side effects.

I'll assume it's not a synchronization issue since you deleted all the temp files and restarted.

There is a possibility that the compiler has performed some serious optimizations that cause the executable to not match the listing.

Here are some examples.

Removal of empty functions A favorite of the compiler and linker developers is to remove functions that have no content or that are not used. This plays havoc with the symbolic debugger, because the source code says the function exists, but the compiler / linker removed it.

Compiler created common code
The compiler may have factored common code among functions. The new function containing the common instructions is usually placed at the end of the module. This confuses the debugger because there is no matching line number to the new code or there are multiple line numbers referring to the new code.

Compiler rewrites your code
I've had this happen. The assembly language listing shows no assembly code for the source code, since the compiler decided to rewrite the code. A good example is inlining. I had a simple loop of 5 iterations and the compiler replaced the for loop with 5 copies of the loop contents. Doesn't match the source code listing, so the debugger is confused.

Truth in the assembly listing
The truth is in the assembly listing. If you post either the assembly language for the function or an interwoven listing of assembly language and C++ language, we can give you better details of the cause of the debugger jumps.