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.
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.
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.
Related
I am using visual studio for last few months. When I trace a C program
it will show line by line execution including the lines in the header files. It will take lot of time to trace it.
In addition to #NathanOliver's comment about breakpoints, make sure you're also using "Step Over" (F10) instead of "Step Into" (F11) (here's more info on that).
If you truly want to change what functions are stepped into, you can do that on a per-function basis by editing default.natstepfilter (see this link), but I don't think you can do it on a "skip all headers" kind of thing.
Basic method of all debugging:
1)Know what your program is supposed to do.
2)Detect when it doesn't. Print some values with printf()
3)Fix it.
This link might be useful.
Use the last version Visual Studio. It has the Just My Code option enabled by default. This makes the debugger skip "not that interesting" standard library code, including inline functions in system headers.
I want to extend the features of C/C++ compiler used in Visual studio. Basically, I want to write a tool which parses the c/c++ code and prints out where all branching (if check, break statement, for/while loops, etc) happens in the code. Then I would like to use this information while executing code to grey out areas of code that have not been executed, for a given testcase.
Is it possible? Does Microsoft provide any way to add features to its compiler/debugger?
--Thanks
Microsoft's compilers always were a black box. (Taken from their own site from the upcoming link). So you have a chance that it is not possible right now. But with project Roslyn that's about to be changed.
Anyway, it seems to me you shouldn't look into the compiler but the debugging part of Visual Studio. There are APIs that allow you to interact with the debugger and that's probably the road you want to take (and others did take).
You would not normally do that by modifying the compiler, and with Microsoft's compiler you cannot in any case. Rather you would write a preproccessor that instruments the code (inserts additional code at the conditional nodes to trace the control flow), and then a tool that process the trace data to determine what ran.
Visual Studio itself has an add-in architecture that would allow you to render this data in the editor in the manner you describe.
The instrumentation itself is not trivial - it will need to be able to parse all valid C and C++ code and be able to retain the original line number information so that the uninstrumented code can be presented. For completeness it would have to be able to re-factor code using the ternary ?: operator so that its flow could be instrumented. The instrumented code would also need to be the code output by the standard pre-processor rather than the original source code - making line number tracking a little more difficult (although the preprocesor already manages that for use with the debugger).
Use preprocessor to instrument code. Code should spit out a file while running. At breakpoints, process this information and "grey out" code using debugger APIs + visual studio addin mechanism.
I'm compiling a very small Win32 command-line application in VS2010 Release-Mode, with all speed optimizations turned on (not memory optimizations).
This application is designed to serve a single purpose - to perform a single pre-defined complex mathematical operation to find a complex solution to a specific problem. The algorithm is completely functional (confirmed) and it compiles and runs fine in Debug-Mode. However, when I compile in Release-Mode (the algorithm is large enough to make use of the optimizations), Link.exe appears to run endlessly, and the code never finishes linking. It sits at 100% CPU usage, with no changes in memory usage (43,232 K).
My application contains only two classes, both of which are pretty short code files. However, the algorithm comprises 20 or so nested loops with inline function calls from within each layer. Is the linker attempting to run though every possible path through these loops? And if so, why is the Debug-Mode linker not having any problems?
This is a tiny command-line application (2KB exe file), and compiling shouldn't take more than a couple minutes. I've waited 30 minutes so far, with no change. I'm thinking about letting it link overnight, but if it really is trying to run through all possible code paths in the algorithm it could end up linking for decades without a SuperComputer handy.
What do I need to do to get the linker out of this endless cycle? Is it possible for such code to create an infinite link-loop without getting a compiler-error prior to the link cycle?
EDIT:
Jerry Coffin pointed out that I should kill the linker and attempt again. I forgot to mention this in the original post, but I have aborted the build, closed and re-opened VS, and attempted to build multiple times. The issue is consistent, but I haven't changed any linker options as of yet.
EDIT2:
I also neglected to mention the fact that I deleted the "Debug" and "Release" folders and re-built from scratch. Same results.
EDIT3:
I just confirmed that turning off function inlining causes the linker to function normally. The problem is I need function inlining, as this is a very performance-sensitive operataion with a minimal memory footprint. This leads me to ask, why would inlining cause such a problem to occur?
EDIT4:
The output that displays during the unending link cycle:
Link:
Generating code
EDIT5:
I confirmed that placing all the code into a single CPP file did not resolve the issue.
Nested loops only affect the linker in terms of Link Time Code Generation. There's tons of options that determine how this works in detail.
For a start I suggest disabling LTCG alltogether to see if there's some other unusual problem.
If it links fine in Release with LTCG disabled you can experiment with inlining limits, intrinsics and optimization level.
Have you done a rebuild? If one of the object files got corrupted, or a .ilk file (though release mode probably isn't using one, I can't be sure about your project settings), then the cleaning pass which rebuild does should cure it.
Closing and re-opening Visual Studio is only helpful in cases when the debugging (or one of the graphical designers) is keeping an open handle to the build product.
Which leads to another suggestion -- check Task Manager and make sure that you don't have a copy of your application still running.
If the linker seems to be the bottle neck and both classes are pretty short, why not put all the code in a single file? Also, there is a multi-processor compilation option in visual studio under C++ general tab in the project settings dialog box. Both of these might help.
Some selected answers:
Debug builds don't inline. Not at all. This makes it possible to put breakpoints in all functions. It wou
It doesn't really matter whether the linker truly runs an infinite loop, or whether it is evaluating 2^20 different combinations of inline/don't inline. The latter still could take 2^20 seconds. (We know the linker is inlining from the "Generating code" message).
Why are you using LTCG anyway? For such a small project, it's entirely feasible to put everything in one .cpp file. Currently, the compiler is just parsing C++, and not generating any code. That also explains why it doesn't have any problem: there's only a single loop in the compiler, over all lines of source code.
Here in my company we discovered something similar.
As far as I know it is no endless loop, just a very long operation.
This means you have to options:
turn off the optimizations
wait until the linker has finished
You have to decide if you really need these optimizations. Here the program is just a little helper, where it does not matter if the program is running 23.4 seconds or 26.8. The gain of program speed compared to the build speed are making the optimizations nearly useless. At least in our special scenario.
I encountered exactly this problem trying to build OSMesa x64 Release mode. My contribution to this discussion is that after letting the linker run overnight, it did complete properly.
When I'm using my debugger (in my particular case, it was QT Creator together with GDB that inspired this) on my C++ code, sometimes even after calling make clean followed by make the debugger seems to freak out.
Sometimes it will seem to be lined up with another piece of code's line numbers, and will jump around. Sometimes this is is off by one line, sometimes this is totally off and it'll jump around erratically.
Other times, it'll freak out by stepping into things I didn't ask it to step into, like while stepping over a function call, it might step into the string initialization routine that is part of it.
When I get seg faults, sometimes it's able to tell me where it happened perfectly, and other times it's not even able to display question marks for which functions called the code and from where, and all I see is assembly, even while running the exact same code repeatedly.
I can't seem to figure out a pattern to what causes these failures, and sometimes my debugger is perfectly well behaved.
What are the theoretical reasons behind these debugger freak outs, and what are the concrete steps I can take to prevent them?
There's 3 very common reasons
You're debugging optimized code. This rarely works - optimized code can be reordered/inlined/precomputed/etc. to the point there's no chance whatsoever to map it back to the source code.
You're not debugging, for whatever reason, the binary matching the current source code.
You've invoked undefined behavior somewhere - if whatever stuff your code did, it has messed around with the scaffolding the debugger needs to keep its sanity. This is what usually happens when you get a segfault and you can't get a sane stack trace, you've overwritten/messed with the information(e.g. stack pointers) the debugger needs to do its job.
And probably hundreds more - of the stuff I personally encounter is: debugging multithreaded code; depending on gcc/gdb versions and various other things - there's been quite a handful debugger bugs.
One possible reason is that debuggers are as buggy as any other program!
But the most common reason for a debugger not showing the right source location is that the compiler optimized the code in some way, so there is no simple correspondence between the source code and the executable code. A common optimization that confuses debuggers is inlining, and C++ is very prone to it.
For example, your string initialization routine was probably inlined into the function call, so as far as the debugger was concerned, there was just one function that happened to start with some string initialization code.
If you're tracking down an algorithm bug (as opposed to a coding bug that produces undefined behavior, or a concurrency bug), turning the optimization level down will help you track the bug, because the debugger will have a simpler view of the code.
I have the same question like yours, and I cannot solve it yet. But I have came out one problem solution which is to install a virtual machine and install Unix system in it. And debug it in Linux system. Perhaps it will work.
I have found out the reason, you should rebuild the project every time you changed your code, or the Qt will just run the old version of the code.
just like in topic - is there any software to open (what?) and here I don't even know what to open - file with object code or exe?
My today's questions (if only todays ;)) may seem bit odd but I'm going through excersises in "The C++ Programming Language" by B.S. and sometimes I'm just stuck on particular question. I'm sometimes bit irritated by style of this book (excellent in many aspects) that he (B.S.) asks some questions which you won't find answer in his book on how to do it or even where to start.
Like this one for example:
Run some tests to see if your compiler really generates equivalent code for iteration using pointers and iteration using indexing. If different degrees of opimization can be requested, see if and how that affects the quality of the generated code.
Thats from chapter 5 question 8. Up to this point nowhere in this book is even mentioning testing and analyzing code generated by compiler.
Anyway, if someone could help me with this I'll be greatful.
Thank you.
The debugger will help you. Most debuggers let you halt the program and look into disassembly. The nice thing is they point you right to disassembly of the line you set the breakpoint to, not to just all the compilation result.
Once in a while I do that in Visual Studio - compile the program, put a breakpoint onto the beginning of code of interest, start the program, then when it is halted I open the disassembly and immediately see the code corresponding to that C++ code.
If you're using g++, you can do g++ -S main.cpp. This will output the assembly in a file called main.s. However, if the functions you're interested in are spread across different .cpp files, it might be more convenient to do an objdump on the final executable.
There's also a nice tool called embroider that pretty-prints the objdump output for you as HTML, crosslinking the various function calls and jumps.
Many compilers can generate "listing" files of the assembly code they are generating during compilation, interspersed with the statements from the C source code. Also, there are tools which disassemble object and executable files.
How these tools are actually activated is depending on your toolchain, obviously.