Any way to speed this up without losing any of the debugging functionality?
Compared to debugging with clang on mac/linux the generated code is horribly slow.
You could also try to disable debug heap by setting _NO_DEBUG_HEAP=1
See here more information about that:
http://ofekshilon.com/2014/09/20/accelerating-debug-runs-part-1-_no_debug_heap-2/
Find out why it's slow. This is how I find out. My off-the-cuff-probably-wrong guess is it could be in data validation. When you find out what it's doing you can probably turn it off by tweaking some compiler flags.
A way to do that is to make a release configuration, clone it, and then turn on symbol-retention and turn off compile-time optimization.
This way you can debug it, but without turning on all the data structure validation, index checking, debug-new, etc .
This blog post has the full explanation of the OP's solution - referred to in his comment on Nikolay's answer: "I gained alot more back by setting "basic runtime checks" to Default. This got me almost to the speed of clang's debug builds."
This solution still works for the same problem in VS 2015.
Related
Is there a way to run my .fs file with either a breakpoint or a command like System.Diagnostics.Debugger.Launch() in it so that I can use FSI to examine values, apply functions to them, plot them, etc.?
I know this question has been asked before but I tried the answers and could not make them work. Clear instructions or a link to a write-up explaining the process would be of great help not only to myself, but also, I believe, to all beginners.
Unfortunately, you cannot hit a breakpoint and jump into FSI. The context of a running .NET program is quite different to that of an interactive FSI session and they are not compatible enough to just switch between one or the other. I can understand an expectation of this kind of debugging when coming from other dynamic/interpreted languages such as JavaScript, Python etc. It is a really powerful feature.
As you have already noted, you can use the VS immediate window but you need to use its C#-like syntax and respect its limitations. Also, since it's not F#, you need to understand the F# to .NET conversion in order to make full use of it.
If you use Paket for dependency management in your project you have another option: Add generate_load_scripts: true to your paket.dependencies. This will give you a file like .paket\load\net452\main.group.fsx, which you can load into FSI to get all of the dependencies for your project. However, you are still responsible for loading in your own source files and building up some state similar to what is found at your desired breakpoint.
To hit a break point, in visual studio or visual studio code, you just click to the left of the line number you want to set your breakpoint. This is very much a supported feature in .fs files.
I'm having a weird problem with Visual Studio 2010 Ultimate:
One of my Nunit(2.6.2) test cases is failing in the debug mode but passing in the run mode, as if we had completely different code paths for the two scenarios.
Is this a known bug? or is there some option in vs I'm missing?
Please enlighten me!
Thanks a lot.
EDIT - MORE INFORMATION
My application submits some requests to a dll written by a group of people within the organization. The dll does some computation and returns the results back to me.
In a test case exploring the dll's behavior (e.g. submit a request having certain parameter, check the dll's output), running the Nunit test works fine, but debugging the test case gives me an error - an exception was thrown from within that dll.
IMPORTANT: Running/debugging another test case gives me consistent results.
So, for the weird test case:
1, either the dll is good, and something under the debug mode breaks the dll
2, or, the dll has a bug, which is triggered by something under the debug mode.
To my knowledge, the ONLY difference between running and debugging a piece of code in visual studio is that, when debugging, a pdb file is loaded while when running it's not. Essentially, a symbol table is loaded to identify code execution.
Then the issue doesn't make sense in the first place - why would loading a symbol table affect the dll's behavior? (It's unfair to ask anyone to give an explanation without seeing any code; however, since it's corporate prop. code, I can't show it here. Please, if you've ever encountered such things in your career, do share with me what happened in your case - let's hope my problem has the same cause so that I can actually know what went wrong. Thanks)
Are you using code coverage?
If so, try disabling it and run. It will probably work.
For more details, check: http://social.msdn.microsoft.com/Forums/en-US/aba3d58f-f19f-4742-b960-8ac2be29bb88/unit-test-passes-when-in-debug-but-fails-when-run
You may have run into a situation where you're taking the same code path, but the results are subtly different in debug vs non-debug due to optimizations. There are a couple of distinct possibilities here:
Your code has a subtle bug, e.g. a race condition
Your test is being overly specific, e.g. for floating point comparisons where you should use a tolerance
It's a pain not being able to debug, but I suggest you add logging throughout the method and the test so you can see what's going on. (And hope that the logging itself doesn't change the test result, which is also possible...)
Thank you for your response.
I've identified the reason: it's due to a false parameter which drives the dll nuts. My bad.
It still doesn't answer the question why the behavior at debug time goes crazy, but good while running the test case.
However, I guess, since the parameter is wrong in the first place, I can't really blame the dll for going nuts. Anyway, when I passed in the correct param, all went good.
Thanks a lot guys.
I'm using VC10 (but I guess this applies to VC9, VC10 and VC11). In short, I want to compile a release library, ship it and allow users to be able to link to that library when making a debug or release build of their application. Annoyingly I keep getting the LNK4204 error, for example:
mylib.lib(an_object_in_my_lib.obj) : warning LNK4204: '[PATH TO USER APPLICATION INTERMEDIATE DIRECTORY]\vc100.pdb' is missing debugging information for referencing module; linking object as if no debug info
Fine. I understand what this is saying. My initial reaction was "well, it's going to be trivial to turn this off". However I can find no way of preventing this. Things that have surprised me are:
I can't find any option in the library project setting to compile without debug info (even in release!) - and by God I could swear there is a way!
I can't find any option in the user application project settings to instruct the linker that I know there's no debugging info and it should just get on and do what it's told!
Is there any good solution to this? Presumably it's not uncommon to want to link to a library with no debug info but produce debug info for the binary I'm creating? What about linking to kernel libraries and crts, surely that's exactly what happens? I can't believe I've never found this problem before, it seems to obvious (can you tell I'm exasperated!).
FYI, before people say it, I really don't want to ship release libs with debugging info as I want to minimize the risk of reverse engineering. I know that some people will say that you'll regret it when a user gets a bug and you have no pdb info, but trust me when I say I don't care about that.
Update:
I believe I've got around the problem but I'm not entirely sure why it works. Definitely need to look into this some more. But in short, I can (and in fact need to) build with VC9. Note that VC9 actually gives you an extra option of "Disabled" for "Debug Information Format", which doesn't appear in VC10; this may explain some of my confusion.
Now the "solution" seemed to be to create a debug version of the library (I'm fine with that) but keep debug info "Disabled". When I do this I get no complaints. It's quite strange as in both cases there's no debug info (the cases being linking debug to release and debug to debug), however when linking to the debug lib I get no warnings. It's a bit of a mystery so far. If I get time I'll investigate it further. Maybe I'm missing something!
The only way to prevent the warning is to supply symbol info. If you're clever you may be able to supply enough symbol info to satisfy the linker, but not enough to raise your imagined risk of making it easier to reverse engineer your code.
Many Qt classes uses pimpl, so they're very opaque to VS's debugger.
This is bothersome when I want to check some internal Qt state to see if my code is doing it wrong or if I'm having wrong expectations of how things stand.
I'm using the Qt VS add-in (1.1.0), but that doesn't seem to help.
Any ideas?
Update
My autoexp.dat file is filled with Qt stuff, but I'm still not able to look inside the heavier classes (QWidget, QTcpSocket, etc).
I can see the simpler classes contents, so the autoexp.dat below seems to be working, but trying to look inside a QWidget doesn't work.
Update 2
For some reason, after reading comments and looking more, it does work, and I can see the data stuff.
I don't know what happened in the mean time (when I just worked and ignored it), but I did have problems seeing the data before.
I'm accepting the "just works" answer, because I can't delete a bountied question and that's the closest answer available. (The autoexp-dat just pretty-formats the debug lines, using data that's already visible if one digs down)
This might help http://daniel-albuschat.blogspot.com/2008/02/qt-debugging-with-visual-studio-2005.html
IIRC the install of Qt for Windows includes an autoexp.dat file -
Correction, it's part of the the qt-vs-addin
You need to add custom dumpers for your debugger.
There are pre-built ones for GDB. You may have to roll your own for other debuggers, although for visual studio it's possible to get some decent results pretty easily by tweaking the autoexp.dat file. There are plenty of resources online for how to change this file.
Editing autoexp.dat is an option. See http://eecs.vanderbilt.edu/research/hmtl/wiki/pmwiki.php?n=Knowledge.Qt for a set of visualizers.
It seems like you might be out of luck.
Currently this page has the most complete list of macros for QT wariables that can be added to the autoexp.dat:
QT with Visual Studio 2008 (updated for Qt 4.5.2)
ActiveQt also sounds promising, but it might be a bit of an overkill for you.
Beyond this, you would have to roll your own expressions, or maybe write a Visual Studio Debugger Visualizer. (more about that is on CodeProject or MSDN)
Since there is nothing like that out there, it might be a good opportunity for development from scratch. :)
It's definitely possible to look into the pimpl when Qt is compiled with debugging information. Not sure about VS, but with gdb it Just Works™.
I have a workspace for running an H.263 Video Encoder in a loop for 31 times i.e. the main is executed 31 times to generate 31 different encoded bit streams. This MS Visual Studio 2005 Workspace has all C source files. When i create a "DEBUG" configuration for the workspace and build and execute it, it runs fine, i.e. it generates all the 31 output files as expected.
But when I set the configuration of the workspace to "RELEASE" mdoe, and repeat the process, the encoder crashes at some test case run.
Now to debug this is verified following:
Analyzed the code to see if there was any variable initialization being missed out in every run of the encoder
Checked the various Workspace(Solution) options in both the modes (DEBUG and RELEASE).
There are some obvious differences, but i turned the optimization related options explicitly same in both modes.
But still could not nail the problem and find a fix for that. Any pointers?
-Ajit.
It's hard to say what the problem might be without carefully inspecting the code. However...
One of the differences between debug and release builds is how the function call stack frame is set up. There are certain classes of bad things you can do (like calling a function with the wrong number of arguments) that are not fatal in a debug build but crash horribly in a release build. Perhaps you could try changing the stack frame related options (I forget what they're called, sorry) in the release build to the same as the debug build and see whether that helps.
Another thing might be to enable all the warnings you possibly can, and fix them all.
Could be a concurrency problem of two threads. The DEBUG configuration slows the execution down, so the problem does not occur. But, only a guess.
Interesting problem.. Are you sure you have no conditional compilation code lurking around that is not being compiled in release mode? i.e:
#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif
Thats the only thing I can really think of.. Never experienced anything like this myself..
Can you add the debug symbols to the release build and run it in the debugger to see where and why it crashed?
Yeah, those bastard crashes are the hardest to fix. Fortunatly, there are some steps you can do that will give you clues before you resort to manually looking at the code and hope to find the needle.
When does it crash? At every test? At a specific test? What does that test does that the others don't?
What's the error? If it's an access violation, is there a pattern to where it happens? If the addresses are low, it might mean there is an uninitialised pointer somewhere.
Is the program crashing with Debug configuration but without the debugger attached? If so, it's most likely a thread synchronisation problem as John Smithers pointed out.
Have you tried running the code through an analyser such as Purify? It's slow but it's usually worth the wait.
Try to debug the release configuration anyway. It will only dump assemblies but it can still give you an indication of what happens such as if the code pointer jumps in the middle of garbage or hits a breakpoint in an external library.
Are you on an Intel architecture? If not, watch for memory alignement errors, they hard crash without warning on some architectures and those codec algorithm tend to create those situations a lot since they are overly optimized.
Are you sure there are no precompile directives that, say, ignores some really important code in Release mode but allows them in Debug?
Also, have you implemented any logging that might point out to the precise assembly that's throwing the error?
I would look at the crash in more detail - if it's crashing in a test case, then it sounds pretty easily reproducible, which is usually most of the challenge.
Another thing to consider: in debug mode, the variables are initialized with 0xCCCCCCCC instead of zero. That might have some nasty side effects.