failed to attach matlab in Visual Studio 2010 in order to debug cuda kernel

3 views (last 30 days)
Hi I am trying to debug a cuda kernel function via VS but I can not attach matlab with Nsight Debugger. I followed the instruction in the web page:
but matlab can not be attached. Any ideas?
PS: Win 7 64x, Matlab 2011 x64, VS 2010, CUDA SDK 5.5 64x, Nsight 3.1 64x, GForce 9600.

Answers (1)

Joss Knight
Joss Knight on 4 Oct 2013
Edited: Joss Knight on 27 Nov 2015
Debugging kernels from Nsight and Visual Studio using Attach to Process is difficult to get right. I've done my best to come up with a foolproof formula for getting it to work. I'm not 100% sure all the steps are absolutely necessary, so you may find it can be made simpler as you become more familiar with what works for you. Note that typically, order is important here - for instance you need to start the Nsight monitor before you run MATLAB.
1. Install the version of the CUDA Toolkit compatible with your version of MATLAB (type gpuDevice into MATLAB and check the ToolkitVersion). In R2014a, this is CUDA 5.5. You will need to ensure that the SDK is installed, but you should be able to use a later version of the driver and Nsight Visual Studio integration.
2. Run the Nsight Monitor (e.g. from the Start menu). Make sure it is set up to allow attaching to CUDA applications (right-click on Monitor icon in system tray -> select Options -> select CUDA -> change setting "Use the Monitor for CUDA attach" to True).
3. If you are using the same GPU as you are using to drive your display, you may need to disable/modify Windows Timeout Detection. Even if you have a separate compute GPU, Nsight monitor will warn you about TDR anyway so you may still want to make this change (right-click on Monitor icon in system tray -> select Options -> select General -> change WDDM TDR Delay to 10 or higher).
4. Open Visual Studio and open the source file containing the kernel you want to debug.
5. Run MATLAB from Windows Explorer or the Start Menu (as opposed to from a command prompt or Run box).
Info: This has to do with the way MATLAB is launched in a separate process from the command prompt. This has been known to confuse Visual Studio.
6.In MATLAB, set the NSIGHT_CUDA_DEBUGGER environment variable to 1:
setenv('NSIGHT_CUDA_DEBUGGER', '1')
7. Compile your MEX code following the documented instructions for your version of MATLAB (see the online documentation for latest, but older versions use a different process).
It appears that getting Visual Studio to recognise kernel breakpoints initially depends on there being both host and device code debugging symbols present; and also on both the default and Nsight debuggers being attached. These requirements are true for at least the first time you debug your kernel. Typically you want both anyway because you want to debug both your host and your device code. Follow these instructions:
  • For MEXCUDA (R2015b) pass -g (host code debug symbols) and -G (device code debug symbols) directly to MEXCUDA:
mexcuda -g -G mymexCode.cu
  • For earlier versions, pass -g to MEX as above. To get device symbols, override the DEBUGFLAGS variable to add -G:
mex -largeArrayDims -g DEBUGFLAGS="--compiler-options=/Z7 -G" mymexCode.cu
  • Another way is to edit the options file and insert -G into an appropriate place. Use the -v option to check what options where actually passed to nvcc.
Advanced: It is tempting for the advanced user to think they can use the -g option to nvcc rather than --compiler-options=/Z7. However, this uses the /Zi option to the msvc compiler and these symbols are not recognised when attached to MATLAB.
8. Run your code at least once to make sure the mex file is loaded.
9. In Visual Studio, open the Attach To Process dialog in the Debug menu.
10. Attach the default debugger by selecting MATLAB in the list of processes and clicking Attach.
Info: As mentioned above, attaching the default debugger may not be necessary in subsequent debugging runs.
11. Now open the Attach To Process dialog again.
12. Change 'Transport' to 'Nsight GPU Debugger'. Make sure your computer hostname is still selected in the 'Qualifier' box.
13. All being well so far, MATLAB should appear as one of the processes available to attach. Select it and click Attach.
Feedback: The first time you do this you should get a notification from Nsight Monitor by the system tray saying “Connected hostname to hostname”.
14. Put a breakpoint in your kernel code.
Feedback: If symbols are correctly loaded your breakpoint should remain solid red rather becoming hollow with a question mark. Also, it will often move to a new location because not every line of your kernel can be debugged due to optimisations.
15. In MATLAB, run your mex function again. The breakpoint should be hit and bring Visual Studio to the front. Start your debugging.
These are some other things that may help:
  • In the Visual Studio Attach To Process dialog, the “Attach to:” box should automatically say “Automatic: Native code” if your code is not in a Visual Studio project. If you are having problems with this try changing this via the Select… button and make sure both Managed and Native code are selected. (This option can make Windows ignore breakpoints in code that isn’t managed by a Visual Studio project.)
  • Try opening the Modules window in Visual Studio (Debug -> Windows -> Modules) and check that your mex file appears in the list with the Symbol Status saying “Symbols loaded”. If it doesn’t say this you definitely do not have debug symbols loaded for your file. Also check that the path to the file is the same as the path to the file in the editor where you have set your breakpoints.
  5 Comments
Joss Knight
Joss Knight on 26 Apr 2017
Follow the steps closely. The NSight Monitor must be running before you open Visual Studio.
Aaron Meldrum
Aaron Meldrum on 1 Apr 2019
Has this process changed since this was initially answered, specifically for Visual Studio 2017? I've attempted to precisely follow this procedure outlined on multiple computers (gpu specs detailed below), and am encountering the same issue on both. The main issue is that at step 13 MATLAB does not show up when I select the NSight GPU Debugger. When I check the 'modules' window, I do not see anything related to the mex file I'm trying to debug, however i do see a list of 500 files, and for nearly all of them the pdb file could not be located. The mexcuda file compiles and runs fine (except for the error i'm trying to debug) on both computers using Matlab R2018b.
Computer 1: Nvidia GTX1050 (only used for display) + 4x Nvidia Titan V
Computer 2: Nvidia Geforce GT730(only used for display) + 4x Nvidia Tesla K80
For the first computer there seems to be an issue with the older NSight debugger not working with a Titan V, and the next-gen debugger not supporting 'Attach to process' yet. I'm not sure if there is a workaround for that.
The second computer seemingly should work, though, and I'm encountering the same issue.

Sign in to comment.

Categories

Find more on Get Started with GPU Coder in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!