Unable to set breakpoints in kernels, debugging not working, VS2017 15.9.6

Developer Tools Nsight Visual Studio Edition
1

Hello,

I’m using VS2017 15.9.6, and NSight Visual Studio Edition 6.0.0.18227. I have a GEForce GTX 1060 running gdriver version 417.35 on Win10 Pro.

I am running Nsight Monitor 6.0, and it’s main page says ‘The Nsight Monitor on … is properly configured for Nsight GPU debugging and analysis seessions’ (but then ‘Connections: (no connections)’

Before starting the debugger in VS, I set a breakpoint inside a CUDA kernel function. Then, in VS I choose Nsight->Start CUDA Debugging (Next-Gen)…

The debugger starts the process (a simple console app), but all breakpoints in the kernel function disappears. I can breakpoint in host code (e.g. main()) and step through host code but cannot step into nor breakpoint in the kernel function. The kernel function is definitely being called.

During debugging, the Nsight Monitor 6.0 still shows ‘Connections (no connections)’.

Both ‘Device’ and ‘Host’ have ‘Generate GPU Debug Information’ are set to ‘Yes (-G)’

All other settings are default and unchanged from initial install.

What steps can I take or diagnostics can I run to understand why I cannot debug CUDA kernels in VS2017?

Thanks in advance for your help.

2

BTW, I upgraded to NSight Visual Studio Edition 6.0.0.18297 and the behavior is the same (unable to set breakpoints in kernel function).

3

Hi Eric,

I have a setup similar to yours (VS2017, NSight 6.0.0.18297, GTX 1070, Windows 10 Pro, latest Nvidia drivers 418.xyz). I’ve spent the last two days hitting my head on my desk because I could not succeed to break in my CUDA code.

Finally, I decided to install the graphics drivers recommended by Nvidia with my version of NSight, which is version 411.63.

Now it works for me.

Give it a try, maybe it will also work for you.

Cheers,
Fred

4

Thanks Fred, good advice.
I am running that version of the driver, which was a good thing to check.

I can breakpoint in a kernel now (not sure what changed), but the VS behavior is non-intuitive.

  1. I set a breakpoint in a kernel (red tomato in the margin of the editor on the line in the kernel)
  2. I start the exe in the debugger.
  3. the red tomato next to the kernel line of code disappears (so I think no breakpoint…)
  4. When the kernel line is executed, the debugger breakpoints and the tomato (and the yellow indicator) appears on the line I had originally set the breakpoint.

So…why the red breakpoint tomato disappears when I start the debugger, IDK. But, aside from that behavior, I think it is working for me now.
-E.

5

Cool. Happy to know it’s working now.

Usually this kind of behavior with breakpoints (red tomatoes ;) in VS happens when a breakpoint is set in a piece of code that is not loaded at application start, but gets loaded dynamically later in a DLL for example. The breakpoint disappears and reappears when the code and symbols are loaded.

I’ve been working with VS for a long time, but CUDA debugging in VS is new to me. Is it a normal behavior with NSight? No idea.

Fred

1 Like
6

Right, very similar with CUDA. The Kernel must be launched and and symbolics loaded in order to resolve the source code break on the runtime instance. At this point, all the kernel breakpoints will turn from hollow to red.