I am using NSight to debug my CUDA code and I have question:
how can I place a breakpoint for a specific thread and block?
When I place a breakpoint on the kernel the debugger always stops at thread 0 of block 0.
As discussed in the online help in Nsight, you can set a breakpoint and make it conditional on block and thread id like this:
To set a block or thread condition on a CUDA C breakpoint:
Set a breakpoint on a line of source code.
Right-click on the breakpoint.
From the drop-down menu, select Condition...
Type:
#blockIdx(0,2,0) && #threadIdx(5,0,0)
Click OK. The breakpoint glyph shows a plus sign.
try to use CUDA Debug Focus. you can debug any thread in any block you want...
Related
As the pic I show here.
I set a breakpoint at the line
w.show();
However, when I press F5 to debug. It doesn't stop at this line directly.
It stop to other lines in other files which I haven't set breakpoint many times. After that it stop at the line which I have set breakpoint. It is a waste of time. Why debug doesn't stop at breakpoint directly?
I solve my question. Just clear all the breakpoints in all project. Although there is just one breakpoint in my testing project
In Visual C++ 2015, the memory debugger window shows
"Unavailable when debuggee is running."
when the process is running.
Is it possible to show and reevaluate the memory at a certain address without pause the process, like a live view?
Yes, it is possible. Place a breakpoint, open breakpoint settings button (gear) and set action to print log message containing the value of variable of interest such as {var_name}. Example:
auto i{0u};
for(;;)
{
++i;
}
will print the value of i into VS output window every 10000 iterations.
This screenshot if from VS2017, but it should probably work for VS2015 as well.
I'm debugging C++ program compiled with MSVC under Windows.
I want to investigate issue linked with multi threading. So I put ASSERT in my code and when program reaches ASSERT it displays window about ASSERT (Standart [Abort], [Retry], [Ignore] window) with proposal to pause program in debugger. I press [Retry] button and program pauses. BUT while I was pressing the button other threads continue to execute.
So the question is how to immediately stop the program when it reaches some point to see what other threads was doing at that time?
You might want to set a conditional breakpoint instead of using an assert:
In case you want to do it programmatically, use DebugBreak. (C# has an equivalent api System.Diagnostics.Debugger.Break)
In case you want to do it from ide, from the msdn page you can put a breakpoint (or break all the application, ctrl+alt+B) from visual studio and then control the thread execution using "freeze" and "thaw" in the thread window.
In the Microsoft Windows API, you can use SetUnhandledExceptionFilter, to set a handler for unhandled exceptions. The big catch, mentioned on that page, is:
If an exception occurs in a process that is not being debugged, and
the exception makes it to the unhandled exception filter, that filter
will call the exception filter function specified by the
lpTopLevelExceptionFilter parameter.
(emphasis added)
Which basically means, if the process is getting debugged, the debugger gets the exception, and my filter is skipped!
I can test & debug my ExceptionFilter the old-fashioned way, with printfs and trial-n-error.
But am I missing something? Is there a good way to interactively debug an ExceptionFilter if it is disabled when in a debugger?
Checkout the Resolution section of KB173652 which talks about placing all the code in main/WinMain in a _try/_except block like the following.
void main (int argc, char **argv)
{
__try
{
// all of code normally inside of main or WinMain here...
}
__except (MyUnFilter (GetExceptionInformation()))
{
OutputDebugString ("executed filter function\n");
}
}
Another article, Debugging custom filters for unhandled exceptions, describes a couple more techniques in addition to the one above. I personally use the one where you display a message box inside your exception filter and then attach the debugger. I use IsDebuggerPresent to determine whether to display the message box or not.
I know this post has been around for a while, but, I just happened upon it searching for something else. I’m happy to say that what user ‘abelenky’ asks is possible if the filter exists in a separate dll. You can debug an unhandled exception filter using a debugger. I’ve done it, and, here’s how:
The exception filter must exist in a separate dll. You’ll see why later.
You’ll need to add some code to the filter that displays a message box. I use the following code:
#ifdef _DEBUG
AfxMessageBox (_T("At this time, you must attach the debugger to this process in order to debug the filter code."));
#endif
The #ifdef is important because you don’t want the code executing in a Release build. I placed the above code at the very top of my filter.
To debug the filter:
Build a Release version of your application in Visual Studio
(instance #1).
Build a Debug version of your filter in a second instance of VS (#2).
Copy the Debug version of the filter to the Release folder of your
application.
Start your Release application from the Debug menu “without
debugging”.
Cause a crash in your application.
When the debug message box (above) appears, change to the second instance (#2) of Visual Studio.
In the #2 instance, open the filter project in Debug (if it isn't open) and attach the
debugger to your Application instance.
Set a breakpoint in your filter code after the message box displays.
Close the message box and your breakpoint should be hit.
Continue to debug your code.
My program is using too much CPU power when I select text. And I don't know why. Normally I'd just press "Break all" to see what the program is currently doing. But in this case I'm busy selecting text with the mouse.
Is there any trick to delay the "Break all" command for a few seconds?
you can start a separate thread with Sleep(5000); DebugBreak();
Press CTRL-Break while selecting. This should bring the debugger up immediately.
You can sprinkle all your suspicious code with special kind of breakpoints that do not stop execution, but print a message in Output window.
Add a breakpoint, go to Breakpoints window, find the breakpoint that was just added, right-click, select "When Hit...", in new window select "Print a message". Make sure check box "Continue execution" is checked (it should be by default). Breakpoint icon will change from circle to diamond. Repeat this for several breakpoints.
You can adjust the text that breakpoint will display to whatever you need.