I am trying to dive in a really big codebase. I am using Visual Studio Code. I always used debugger with setting the breakpoints, but this time I just would like to become familiar with a new codebase and see where is the code responsible for particular program commands execution. Is there an option to run debugger step by step without setting breakpoints in VSC? Or where can I find e.g. what functions where called during my program execution? In Call Stack section I see only the threads number.
I see a command
editor.debug.action.runToCursor
if you don't want to set breakpoints. It has no default binding so you will have to make your own. I tested it and it works. When your code stops - at your cursor - you should see the call stack (assuming the call stack panel is not hidden).
Related
When I run my code I get this error:
"source information is missing from the debug information for this module."
I use callbacks in my code in C++ concert CPLEX. When I run the code without using a callback I don't see the error message but when I use callback I do see the error message. Some of the parameters in my code are matrix 10*5. When I run the code with matrix 5*5 I don’t get any error but with matrix 10*5 I get an error.
I don’t have any information about dll and PDB file. I don’t know how to fix this error in visual studio 2015 on windows 10? I read some topics about this error on StackOverflow but I mixed up and I don’t know which one is good for my problem.
This message about source information missing is an informational message and not really an error. What it is saying is that you are trying to single step with the debugger through a part of your program for which the debugger does not have the source code. The result is that you can step through the program viewing the assembler generated by the debugger but the debugger can not show you the actual source code of the program at the point you are currently looking.
The fix for this is to get the source code and make it available to the debugger.
However you may not need to do this.
What it sounds like is happening is the following.
You are stepping through your program with the debugger and at some point the CPLEX functionality, which is doing some kind of an asynchronous task in parallel with the part of the program you are stepping through begins to perform some kind of action that will result in your callback being triggered. The current instruction is within the CPLEX functionality and the debugger does not have access to the source code and the descriptive information in the .pdb file generated by the compiler.
This article, Specify symbol (.pdb) and source files in the Visual Studio debugger (C#, C++, Visual Basic, F#), about the Visual Studio debugger has this to say about the informational message you are seeing:
There are several ways for the debugger to break into code that does
not have symbol or source files available:
Step into code.
Break into code from a breakpoint or exception.
Switch to a different thread.
Change the stack frame by double-clicking a frame in the Call Stack window.
Background on callbacks and asynch processing
Some background information on the callback concept: Wikipedia article Callback (computer programming), What is a callback function? , What is a "callback" in C and how are they implemented? .
When you are not using callbacks then there is no asynchronous task being performed, the use of CPLEX is synchronous in that you do a call into a CPLEX function, it returns with a result, and then your program continues after waiting for the result. With asynchronous, you do a call into the CPLEX functionality that starts an asynchronous task and then immediately returns without finishing with the expectation that when the task does finish, your callback will be triggered.
When CPLEX triggers the callback, because you are single stepping and the program does a sudden transfer of control to the CPLEX functionality between one step and the next in the debugger, you are suddenly single stepping through the CPLEX source code but the debugger doesn't have that source. So it issues an informational message telling you that it can't find the source and giving you other options.
Workaround debug procedures
What I do under these circumstances is to set a breakpoint in the callback so that if I then just do a Run command, the callback will be triggered and then execution will stop at that breakpoint in my source and then I can continue single stepping through the callback function source.
The problem you may run into is when the callback is on one thread and the other execution path you were following is on another thread. Then what happens is the debugger is swapping between the two threads of execution and single stepping becomes more difficult as the running thread changes from one place in your program to another. To get around this usually requires setting breakpoints or manually changing the currently executing thread with the debugger.
However if this functionality is single threaded then you should be able to just set the breakpoint in the callback and then when the callback is triggered by the CPLEX functionality, execution will jump to that point and hit the breakpoint. You can then single step through the callback functionality and when it returns back to the CPLEX functionality just press Run to let it continue.
I have a .NET Core 2.0 C# program that starts another .NET Core 2.0 C# program. I want to automatically attach the VS 2017 debugger to the sub-process, either as soon as it starts or at a certain point in its execution.
I tried adding a System.Diagnostics.Debugger.Launch call to the sub-process code and this does pop up the VS JIT debugger dialog, but:
If I don't check "Manually choose debugging engines" it debugs only native code. The process is stopped at a breakpoint, as expected, but I cannot debug my C# code.
If I do check it and check "Managed" I still cannot uncheck "Native" - it says "For the debugger to handle the current exception, 'Native' code must be selected." It then starts mixed-mode debugging, but does not enter break mode. If I break manually I can see that the thread that called Debugger.Launch has the following stack trace:
ntdll.dll!ZwWaitForMultipleObjects()
KernelBase.dll!WaitForMultipleObjectsEx()
kernel32.dll!WaitForMultipleObjectsExImplementation()
[Managed to Native Transition]
(my method that called System.Diagnostics.Debugger.Launch)
It's just "stuck" in this method and I cannot step out of this to continue running my managed thread, so this is completely useless.
How do I attach the debugger in such a way that I can stop at a breakpoint, inspect managed variables and then continue?
Debug.Assert is probably the easiest if they own the second process. Assuming that’s available in .NET Core.
You could look here for more information on why their Debugger.Launch is behaving like it does:
https://blogs.msdn.microsoft.com/jmstall/2006/02/16/ifeo-and-managed-debugging/
This question already has answers here:
debugging a process spawned with CreateProcess in Visual Studio
(3 answers)
Closed 7 years ago.
I have a program running which loads up a separate program to do some work for it. That separate program is run from the first, using Process.Start() and I need it to load into the Visual Studio debugger to single step through it.
Unfortunately, though I can run the first program in a debugger session, it still starts the second as a "proper" process. I need to have this second program open up in a debugger session. Normally I would just attach a debugger to the process once it's started but, in this case, I need it to breakpoint very early on (in the CInitDialog() function) and, as fast as I am, I can't outrun the code in this case.
A solution I found right here on Stack Overflow said to use Debugger.Launch() but that appears to be specific to C#.
I also thought of trying to cause a crash in the code (such as with a null pointer reference) to load up the debugger but I suspect this would mean single stepping would then be unavailable to me.
How can I do this?
Visual C++ has a similar feature to the C# Debugger.Launch(), it's called DebugBreak(). This actually breaks the application and it will present you with a dialog box asking how you want to handle it:
If you select Debug the program at that point, it will then ask you whether you want to do it in a new Visual Studio session or an existing one. I tend to have the solution already open so I can effectively attach to that one - opening a new instance gives you just the file rather than the entire solution.
So you can simply insert that call in your code where you want to break, and allow the first program to run it as per normal. The second program will start up and break where you've placed the statement and you can then single-step and do all the other wondrous things a debugger allows.
What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?
I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!
(Assume that the Release and Debug modes are the typical configurations you get when you create a new Visual C++ project.)
The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.
You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1
This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived:
http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx
"Start without debugging" just tells Windows to launch the app as it would normally run.
"Start with debugging" starts the VS debugger and has it run the app within the debugger.
This really doesn't have much to do with the debug/release build settings.
When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:
The emitted code won't be optimised, so is easier to debug because it more closely matches your source
The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.
Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.
When you run 'with debugging' things perform differently for several reasons:
The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.
IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.
IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.
When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.
I have a VB app that I need to monitor while it is running. I added some variables to the Watch window, but while the app is running the watch window is greyed out. The only way that I have found to see the variable values is to use Debug -> Break All, but this stops the program.
I have used other IDEs and they allow active variables to be monitored. Is this possible in VS?
Sorry if this is a noob question.
UPDATE: To be clear, my app is communicating with a piece of lab equipment and and as data is sent or received or errors are detected counters are incremented. I would like to watch these counters but I don't want to build a screen to do this since they are for debugging. I just assumed that this is basic functionality in any IDE
SHOCKED: It seems that Visual Studio does not offer this (what I would consider) basic functionality. For those that seem to think that this is not possible with an interpreted language, consider this thought experiment. If you pressed Break All quickly followed by a Continue then you would refresh the watch window - correct? Why then can't Visual Studio do this as a single Refresh Watch command or better yet allow this function to automatically run at a period specified by the user. No debug writes, no log files, no stopping your program mid-stream and creating timeouts. I am just shocked that you cannot do this. Its a little like not having breakpoints.
Which IDE or development environment shows - in real time - the values of variables in the Watch window, without having to hit any breakpoints, while the application is running?
Visual Studio doesn't provide this. In order to get updated values in the Watch window, or edit items there, the app needs to be at a breakpoint or debugging.
After you've done "break" to give control of the program to the debugger, then you can "step" through the code using function keys like F10 and F11. During each 'step', the program evaluates one or more statements; after each step it stops (until the next step), and while (only while) it's stopped you can 'watch' its current state.
There are other ways too to break into the debugger (to use the Watch window while the program is stopped): other ways like to set 'breakpoints', and use the 'run to cursor' feature.
Of course, but stopping a program that is actively receiving or sending data to a some other process, driver, etc, stops this communication and causes timeouts and other problems.
That's true. To watch values change in real-time, I use a log file:
Add statements to my code, such that when I change the value of a variable I emit a new line to a log file (showing the changed value)
Run the program
Watch new lines being appended to the log file using a utility like tail -f.
I've never see a debugger with the functionality you mention. The closest thing to the functionality you mentioned (and which isn't exactly the functionality you mentioned) is How to: Set a Data Breakpoint (Native Only).
What you're attempting to do is not possible in Visual Studio. All of the variable inspection windows (watch, locals, autos, etc ...) rely on the debugee process being in a break state in order to function.
This is true of essentially any debugger I've worked with in the past. At least those which use a compiled language.
I'm curious as to what IDE's you're referring to? Did they deal with interpreted languages?
Make sure you are in "Debug" build and Microsoft Debugger is running as a service and not blocked/disabled.
This should help you: How to trace and debug in Visual C++ .NET and in Visual C++ 2005
my 88 year old memory remembers an old version of visual studio allowing a watch window to function while debugging.
OK, just me.