The NVIDIA Nsight Visual Studio Edition does not seem to be capable of debugging CPU (host code) and GPU (cuda code) at the same time. With the Nsight Eclipse Edition (or cuda-gdb) this is quite simple, for example, you can "step in" to a CUDA kernel from the host execution. How to do the same with Visual Studio?
From the Nsight manual
It says
Use a separate Visual Studio instance to debug the host portion of a
target application. If you wish to debug the host portion of your CUDA
application while the CUDA Debugger is attached, you must attach using
a different Visual Studio instance. Attaching the same instance of
Visual Studio to debug both the host portion and the device portion of
a target application will cause the debuggers to conflict. The result
is that the target application and the CUDA Debugger hang while being
blocked by operations of the native debugger.
So to debug a CUDA application here are the steps:
Open Visual Studio (VS instance #1) and set a breakpoint in a CUDA kernel and click "Start CUDA Debugging." This will start the application instance and stop where u set the breakpoint.
Open another instance of Visual Studio (VS instance #2) (needs to be run as admin for some reason) and attach to the process you started in step 1.
In VS instance #2 browse to the file you wish to do your CPU debugging and set a breakpoint.
In VS instance #1 continue the execution (should fall out of the current CUDA kernel). At this point the CPU breakpoint you set in VS instance #2 should be hit.
Extra credit: Debugging your CUDA application remotely.
Steps:
On the target machine run the msvsmon.exe (remote debugger) as admin. This can be found at
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger\x64.
On the host machine (the one from which you want to control the debugging), open VS and make sure the Nsight debugger is pointed to the remote machine (Nsight User Properties > Launch > Connection Name). NOTE: the Nvidia Nsight monitor must be running on the target machine for this to work.
Do steps 1 and 2 from the previous (non-remote debugging) section. In step 2 you will need to point to the remote machine for CPU debugging (Debug>Attach to Process>Qualifier should be set to the target machine name or IP).
The non-remote debugging steps 3 and 4 apply apply here as well.
NOTE: It looks as if VS's remote CPU debugging is not as capable as its local CPU debugging. For example, when you mouse-over CPU variables, there values to not appear as you would expect when you are doing local debugging.
STILL UNANSWERED: Is it possible to start debugging the host code before hitting a CUDA breakpoint? It seems like a big limitation that you can only debug host code following your first CUDA kernel. What if you wish to debug the host code before the first CUDA kernel?
Related
When I 'm remotely debugging an executable, I have it available in the remote machine along with its (500 MB) PDB.
When I start the remote executable, the local Visual Studio takes a LOT of time to finally run it - the messages about DLL's attaching are going super slow in the output window. Debugging is also slow when the app is finally responsive after attaching.
It's like as if it's trying to exchange some debugging information back and forth with my PC, although the EXE and PDB are there.
Is there anything I can do to speed up this? I 've even placed the remote folder for msvsmon to find in tools -> options -> debugging -> symbols.
i have a cpp function (function.cpp") which i "mex"-ed. then i open the function.cpp file in visual studio and attach visual studio to a running matlab process.
when i call the function in matlab i am able to set breakpoints in the function.cpp file and step through it observing the variables.
The debugging process breaks down when i change the function to a cuda file (function.cu). Following the process described above i am still able to stop within function.cu but i cannot see any variables. when i try to "watch" a variable it says "Error symbol .. not found"
i have nsight installed in visual studio. question: how can i observe my variables in the file function.cu in the debug mode as i do for the function.cpp file. Is this possible ?
Note that the function.cu is not in a project. it is just a standalone file with cpp code of a function (say somefunction(){}). for debugging purpose i am opening it up in visual studio. i am compiling the function.cu file in matlab using "nvmex -g wrapper.cu" the wrapper.cu is a matlab mexfunction wrapper which makes calls to somefunction() written inside function.cu
You're using the VS debugger which is a host debugger, so it doesn't know how to debug device programs. To debug device code in Windows you should look at Parallel Nsight Visual Studio Edition.
You can search the docs for a guide to attaching to a running process, for the current release (2.2) the specific page is here.
You attached VS in, but stopped in function 'main'. Looks like you are still hitting the CPU code. When you follow Tom's suggestion to attach the debugger, have you choosed "NVIDIA GPU Debugger" in the Transport dropdown?
To debug any cuda-code you'll need a gpu on which no desktop environment/server is running. For windows that means, that you need a second gpu. I'm not to 100% sure if it has to be a nvida gpu, too. Than you will be able to bedubg your code.
Under linux you're able to debug with only one gpu because you can shut down the x-server and debug with cuda-gdb per command line.
Further informations will give you the cuda-gdb manual
I see that with the 'Attach to Process', one can debug the process by setting up break point in Visual Studio IDE.
I think it's pretty cool, and I'm curious what's the mechanism that enables it. I also found that gdb and Mac's Xcode supports the technology.
Q1 : Can anyone explain how does this work? How can the process mapped to a breakpoint in an IDE or gdb environment?
Q2 : Are there other compiler/debugger options than /Zi or -g (adding debug info)?
Q3 : Is this the way to debug dll (dynamic library)?
ADDED
I found this one with MSDN - http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx
The most common scenario I know of is using a browser to debug web code. In these cases, you start Visual Studio in debug mode and then attach to the browser and call the page in question. When the page is called it starts running the code in the debugger. Essentially, the debugger watches the process and when it hits code in VS, it starts debugging.
The same is true with other applications that are calling code you are running in Visual Studio. When you cross the boundary to the code, the debugger catches the call and starts running code in VS.
I use it fairly frequently when developing plugins for existing applications (Maya, Reaper, etc). As a general rule, plugins can't be run independently, so in order to debug them I have to run the host program and use "Attach to Process" to run the debugger on my plugin, at which point I can set breakpoints and all that other debugging goodness. You need to have debugging symbols and al that for the plugin, but you don't need to have them for the host application.
Is it possible to use windbg commands like !locks and .loadby sos mscorwks from the Visual Studio command window (in a debug session)? I've noticed I can use eg k to print a stack trace, so I was wondering if there is some way to get access to the other commands.
Yes you can do this.
Attach Visual studio 2008 to your process for debugging.
Break at some code.
Go to immediate window
type !load sos
Now you are free to use any of the windbg commands like !EEHeap,!DumpHeap
There are some conditions. You need to enable unmanaged code debugging in your project properties. Normally in 64 bit version studio doesn't support this.
Have fun.
Visual Studio 2012 has the "Windows User Mode Debugger" transport in the "Attach to Process" dialog. This allows you to use windbg commands in the immediate window.
Source: Use the WinDbg Engine in Visual Studio User-Mode Debugging
Starting with Windows Driver Development Kit (WDK) 8.0 the Windows debugger is integrated into Visual Studio (see Debugging Environments). Installing the WDK on top of a Visual Studio installation will enable a developer to pick a number of debuggers from the Attach to Process dialog, or set the debugging engine in a project's Debugger settings. This has been verified for Visual Studio 2012 and 2013. The way I read the MSDN link above, this should also work for any other IDE that is supported by the WDK 8.0 and above.
While WinDbg offers a lot of powerful commands, there are some drawbacks as well. This list is not exhaustive, and merely contains those issues I did encounter:
Cannot attach to more than one process at a time. While not generally an issue, this is quite unfortunate, if you do need to debug more than one process at a time. The Visual Studio debugger can attach to any number of processes simultaneously.
WinDbg will not use the symbol settings from your Visual Studio IDE (tested on VS 2012 Update 4). While you can configure the IDE where to look for debugging symbols, WinDbg will not honor those settings. WinDbg will use the _NT_SYMBOL_PATH environment variable, and/or the configuration set through .sympath.
Different syntax for function breakpoints. This is a minor annoyance, since you cannot use Visual Studio's syntax to specify function breakpoints. This also means, that function breakpoints are ignored that have been set using the Visual Studio syntax. What's more annoying, though, you do get a warning dialog for each when launching a debuggee.
No support for Tracepoints. I've been using tracepoints extensively, to unintrusively insert tracing into a debuggee. If you are using tracepoints as well, this may prove to be more than just an annoyance.
If an application†crashes,
I hit "Debug" and Visual Studio is my currently registered Just-In-Time (JIT) debugger:
Visual Studio appears, but there's no way to debug anything:
I do not see any disassembly
I do not see any registers (assuming it runs on a CPU with registers)
The call stack is empty (assuming the CPU has a stack pointer)
I do not see any symbols (assuming it had any)
I do not see reconstructed source code from reflection (assuming it was managed)
Other JIT debugger products are able to show disassembly, but they are either command-line based (Debugging Tools for Windows), or do not support symbols (OllyDbg, Delphi). Additionally, my question is about debugging using Visual Studio, since I already have it installed, and it is already my registered JIT.
How do you debug a program using Visual Studio?
Alternatively: has anyone written a graphical debugger that supports the Microsoft symbol server?
†Not, necessarily, written in Visual Studio.
Edit: Changes title to process rather than application, since the latter somehow implies "my application."
Edit: Assume the original application was written in assembly language by Steve Gibson. That is, there is no source code or debug information. Visual Studio should still be able to show me an assembly dump.
Looking at the screenshot it appears that Visual Studio is currently debugging in Run mode - you need to break execution of the process before it makes sense to look at things like the call stack, etc...
To break execution of the process you either need to hit a breakpoint, or you can break execution of the process at any time by using the Pause / Break all toolbar item (Control + Alt + Break).
Then you should be able to access the following windows under the Debug -> Windows menu:
The disassembly window
The registers window
The call stack window
The modules window shows a list of loaded modules along with where their corresponding symbols are loaded from (if loaded)
Some other useful windows:
The processes window is useful if you are debugging more than one process at a time
The Threads window
The Memory window (there are four of them)
The Locals window
Some of these might not be visible by default depending on which window configuration you selected when you first started Visual Studio - if you can't find them then right click on the toolbar and goto customise to add them.
Visual studio doesn't reconstruct soucre code from disassembly - you really need to have the original source code available to you, otherwise the symbols almost certainly won't match the source code you are debugging.
If you are debugging unmanaged modules without source code then I recommend you at least try WinDbg - its user interface is a bit clunky at times, and it does have a steep learning curve, however it is a very powerful debugger supporting many features that Visual Studio doesn't - it may be more suited to the sort of debugging you need to do.
(Visual Studio is a fantastic debugger, however it's primarily used to debug modules where the source code is available and so it lacks certain features in favour of a better user experience).
Assuming this is your application that you wrote in VS, just press F5 to run the program and either use a breakpoint, or manually break the program to start debugging.
The problem in the last screenshot is that Visual Studio did not enter break mode automatically. That seems like a bug. If you hit the 'pause' button on the toolbar, it would enter break mode, giving you disassembly, and a callstack.
According to that last screenshot you were actually attached to the program ... the output windows shows it loaded stripped symbols for OLE and the crt.
You can debug a program with Visual Studio if you have the debug information available for this program. It's the difference between compiling a Release version (normally without debug information) and compiling a Debug version.
This dialog to debug a program is handy if you are testing the debug version of your self-written program. You can attach it "on-the-fly" to your Visual Studio debugger and look for the problem.
If it is not your program or it is your program, but does not provide debugging information which Visual Studio can understand, then you are out of luck.
Use menu Debug -> Windows -> Disassembly (I think the keyboard shortcut is Alt + 8, but I am configured for VC 6.0 bindings, because that's how I roll, and it may have changed).
You can get public symbols for the operating system from http://msdl.microsoft.com/download/symbols. Add it to the list in menu Tools -> Options -> Debugging -> Symbols -> Symbol file locations.
Also, make sure you are running in the same integrity level as the application. Or always run Visual Studio as Administrator.
I guess you are already in the Debug mode. The "Run" button is disabled. Just go to Debug -> windows -> Disassembly to view disassembly.