I'm debugging ASP.NET application
I have two breakpoints in this method:
private void Load()
{
Stopwatch t = Stopwatch.StartNew(); //breakpoint A
...
LoadStuff(blah); //breakpoint B
}
When I launch LocalIIS(GoogleChrome) in VS, debugger stops at breakpoint B. Previous Call Stack calls Load(). Moreover, I have a breakpoint from where Load() is being called, it doesn't stop there either. Why it skips breakpoint A? Is there a way not to skip it?
Moreover, I have a breakpoint from where Load() is being called, it
doesn't stop there either. Why it skips breakpoint A?
It seems that breakpoint A is invalid on your side due to some reasons. One possibility is that the referenced DLL is out of sync with the version of the code you are debugging or you changed the code and it is inconsistent with the pdb symbol debugging file.
In first of all, please enable Just my code option in case VS ignores breakpoint A.
Solutions
Make sure optimizations are disabled (this is the defaut for the Debug configuration, but they are enabled in Release configuration). Compiler optimizations can mess with the debugger
Besides, try these steps to generate the latest pdb files from server to match your project.
1.clean the solution
2.Tools-->Options-->Debugging-->Symbols
First empty the old pdb symbol files and remember to choose "Load all modules,unless excluded" from Microsoft Symbol Servers and NuGet.org.Symbol Server.
3.Load all symbols from servers which provides for debugging project
4.Rebuild your project which generates the DLL that matches your project.
You can refer to this for more information. Hope it could help you.
Related
It's basically a Hello, World application with all vanilla settings with the addition of one external library and an init to it. The program takes about 21 seconds to run within Visual Studio using the debugger (F5 or Start Debugging), but runs instantly otherwise. Happens in Release and Debug.
The library is for the Julia programming language. I include it's lib and header directory and simply call jl_init(). Half the stall happens before the line is even hit.
From the command line (cmd to the project dir and type x64\myprogram.exe) or Ctrl+F5 it runs instantly.
From Visual Studio using F5 or hitting "Start Debugging" take about 10 seconds to even reach the jl_init() line which is the very first line of the program. Then another 10 seconds to get through it.
int main(int argc, char** argv)
{
jl_init(); // takes almost 10 seconds to reach this line, before it even runs.
printf("Hello, World!\n"); // takes another 10 seconds to reach this line.
return 0;
}
I'm on VS 2019 v142. Windows 10. The project is on a local SSD. I'm not sure how to tackle this problem. Any ideas?
Edit:
It could be related to loading symbols, but these files are mostly build without symbols though:
'Julia.exe' (Win32): Loaded 'D:\Program Files\Julia-1.6.2\bin\libjulia.dll'. Module was built without symbols.
I'll add that I went into Tools>Options>Debugging>Symbols and selected "Load all modules, unless excluded", then added these dlls into the list of excluded modules. I also unchecked all symbol file location checking in the same dialog. I don't see any indication in the output or the modules debug window that my changes took effect. I also tried disabling ALL symbol loading in Tools>Options>Debugging>Symbols by selecting "Load only specified modules" and specifying no modules. Making these changes didn't help.
I think it's definitely related to dll loading but don't know how.
Edit 2: disabling Tools > Options > Debugging > General “Load debug symbols in external process” made the stall go from 21 seconds to about 12, which indicates it's symbol related.
One of possible issues here is PDB loading.
PDB's are needed to debug libraries, and help debugger resolve callstacks when there are functions from that library in it. In many cases you can debug your app just as well without most of them loaded.
You can disable automatic loading, or set whitelist of modules for which you want to load PDB's following Microsoft documentation: https://learn.microsoft.com/en-us/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2019#symbol-file-locations-and-loading-behavior
I need to set breakpoints in a cpp source file. The current setup to call the cpp target is through a shell target, with additional dependencies, which means it's not feasible to directly invoke the cpp target in Linux console.
As I searched online, there are generally two ways:
invoke gdb in shell
pause in cpp, let gdb connect to the process
I don't know how to do the first way, so I choose the second way here.
I insert sleep(30) in cpp file, then in another terminal I open gdb and connect to the running process. I confirm the gdb can stop at the sleep() function in gdb. But the problem is the gdb seems only knowing the sleep function context, without knowing the call site of the sleep function. If I force setting breakpoint in the main program, gdb shows no such file. If I continue in gdb, it will not stop at any breakpoints I set in cpp file.
You need to compile the program with debug symbols. Otherwise GDB will only know of symbols in the dynamic symbol table. Turning off optimizations also helps debugging. So add the flags -O0 -g.
If this is not possible, you'll have have to step through the disassembly (Ctrl+X, 2).
There is a similar question for address sanitizers, but for thread sanitizers, it doesn't work, I have tried to break on __sanitizer_print_stack_trace, which doesn't work either.
Run the program under GDB, set breakpoints on exit and _exit. On Linux, also set catch syscall exit_group.
set halt_on_error=1 in TSAN_OPTIONS to ask thread sanitizer to exit on first error:
(gdb) set env TSAN_OPTIONS=halt_on_error=1
(gdb) run
... error should be reported and one of the breakpoints should fire.
Profit.
P.S. When the breakpoint is hit, use GDB where command to see how the error is reported. Setting a breakpoint on some kind of __tsan_report_error that is likely on the stack will probably work even without setting halt_on_error.
The first time I enabled Thread Sanitizer on my project, Xcode helpfully added a breakpoint for me in the Breakpoint Navigator. But I deleted it when I was done testing. Now I need it again and Xcode didn't create it for me when I enabled Thread Sanitizer again.
Note that I am using Xcode 11.0 here.
To manually re-create this breakpoint, you need to have the Breakpoint Navigator open. Then click the plus button (+) at the bottom-left of the navigator and select Runtime Issue Breakpoint from the pop-up menu. This adds the breakpoint to the navigator, and a window appears.
From the Type drop-down list, select Thread Sanitizer.
There you go! Silly that this option is buried way down there. But I also found it helpful to note that there are more options for different kinds of breakpoints available from that plus button menu than there are from the main Xcode drop-down menu Debug > Breakpoints.
I am debugging an application and for some reason (which I'm not quite sure), when closing my application abort() is called. I'd like to try and find the reason for this, so I want to place a breakpoint on abort() so I can see the stack trace and hopefully discover the reason it was called instead of a graceful exit.
I am using Microsoft Visual Studio 2012 (Update 3) and only have the declaration for the abort() function (in stdlib.h) and so I can't set a breakpoint. Is there any way to get around this?
You don't need to do anything special. abort call from C/C++ program built by Visual Studio produces the following message:
---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Error!
Program: ...
R6010
- abort() has been called
(Press Retry to debug the application)
---------------------------
Abort Retry Ignore
---------------------------
Pressing Retry opens debugger with full call stack. This functionality is available both for Debug and Release configurations, when program runs in standalone mode and under debugger. In Release configuration the dialog is different, it contains Break button, which opens debugger, like Retry in Debug configuration.
I had the same problem and found this answer which works for me: Press CTRL+B and enter 'abort' in the text field.
Just for debug, you may overrides abort function and set a breakpoint inside.
void abort()
{
std::cout << "aborting" << std::endl; // put break here...
exit(-1);
}
In case of linux gdb, upon hitting abort, you could see easily stack trace with command bt. No need to add extra break point.
I already asked this question in the nvidia forum but never got an answer link.
Every time I try to step into a kernel I get a similar error message to this:
__device_stub__Z10bitreversePj (__par0=0x110000) at
/tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c:10
10 /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c
I tried to follow the instructions of the cuda-gdb walkthrough by the error stays.
Has somebody a tip what could cause this behaviour?
The "device stub" for bitreverse(unsigned int*) (whatever that is) was compiled with debug info, and it was located in /tmp/tmpxft_00005d4b_00000000-1_bitreverse.cudafe1.stub.c (which was likely machine-generated).
The "No such file" error is telling you that that file is not (or no longer) present on your system, but this is not an error; GDB just can't show you the source.
This should not prevent you from stepping further, or from setting breakpoints in other functions and continuing.
I was able to solve this problem by using -keep flag on the nvcc compiler. This specifies that the compiler should keep all intermediate files created during the compilation, including the stub.c files created by cudafe that are needed for the debugger to step through kernel functions. Otherwise the intermediate files seem to get deleted by default at the end of the compilation and the debugger will not be able to find them. You can specify a directory for the intermediate files as well, and will need to point your debugger (cuda-gdb, nsight, etc) to this location.
I think I had such problem once, but can't really remember what was it caused with. Do you use textures in your kernel? In that case you couldn't debug it.