I'm trying to stop WinDbg from displaying source code at all.
I tried to disable by unchecking the Debug->Source Mode option but source code still appear as I step through the assembly.
What can I do to completely disable source code debugging?
I tried the following approaches without success:
unchecking the Debug->Source Mode option
.lines -d command.
l-t command.
Stepping by p and t instead of F10 and F11
this is not an answer to disable the opening of source file window
but a hack to reduce the annoyance it causes
if src window is bothering you on every single step
undock it and reduce its size and place it somewhere in a place where you wont be bothered by it
the other source files in a multi-file project will automatically open in the same place where you put your first undocked source file
you can use alt + w + w to activate any src file if you want to see the source maximize and minimize the window
in the screen shot below 4 src files are open but it wont be annoying you by opening and docking several times and making the command window resize on every source file open
Instead of modifying PDBs or similar, I suggest writing an AutoIt script that closes the source files.
While(True)
CloseWinDbgSource()
WEnd
Func CloseWinDbgSource()
WinWait("[CLASS:WinBaseClass]", ".cpp", 10)
WinClose("[CLASS:WinBaseClass]", ".cpp")
EndFunc
Or you can patch the method windbgx86!WinBase::Create():
0:000> .dbgdbg
and then in CDB
0:000> bp windbgx86!WinBase::Create
0:000> g
[Force opening of a window here]
0:000> bc 0
0:000> a eip
ret
<Enter>
0:000> g
The benefit of that approach is that you don't need to bother with any other windows as well, since no windows will be opened any more.
You can use the .srcpath command to change the source path to an empty directory. Windbg won't have any source code to display.
.srcpath [emptyDirectoryPath]
Your PDB contains the fully qualified path to your source code for each line of assembly. You can see this if you do a "u" command on your function:
kd> u xxx!xxxVolumeEvtIoWrite
xxx!xxxVolumeEvtIoWrite [e:\repos\clients\xxx\xxx\src\xxx_volume.cpp # 1110]:
88c05c60 push ebp
88c05c61 mov ebp,esp
88c05c63 sub esp,38h
WinDbg is going to pop this source code window up if your instruction pointer is on one of these addresses. There is no option to stop this, so the previous answer of hiding the window is a reasonable solution.
Your only other options are to prevent WinDbg from being able to find your source code. You can do this in one of two ways:
Strip the source line information from the PDB so that WinDbg no longer knows the path to the source code. You can do this either with the /PDBSTRIPPED linker switch or with the BinPlace utility
Move your source code to an alternate path so that WinDbg can no longer find it
Related
Whenever I try to step into a function for which I don't have the source code, e.g. anything in an Apple library, the debugger just skips to the next line. How can I have it go into the assembly instead? I can workaround this by setting a symbolic breakpoint for the function that I want to step into, but this is less convenient.
Hold Control when pressing the step controls. Works for me in Xcode 12.
The stepping controls have alternative operations for working with disassembly or threads. You use the Control and Control-Shift modifier keys to call these alternatives. Press Control to step by assembly language instruction instead of by statement (the step icons change to show a dot rather than a line under the arrow) or Control-Shift to step into or over the active thread only while holding other threads stopped (the step icons show a dashed rather than solid line below the arrow).
https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/debugging_with_xcode/chapters/debugging_tools.html
I found that by using mouse click, we can create a red dot as a "marker" in R-studio. This is very nice. But how to simply go to this line with a marker?
I use SAS also. In SAS, it is like pressing Ctrl+F2 to create a marker, and press F2 to go to the next marker.
Anyone use this before? Thanks!
That isn't a marker but rather a breakpoint. When you run a script with a breakpoint, execution will stop there. Unfortunately there isn't currently a way to jump to breakpoints.
You can get similar behavior by inserting sections: use Code -> Insert Section to add a section, then Code -> Jump To to jump to any section quickly (there are hotkeys for these as well).
I'm having a problem with debugging Fortran code within emacs using gdb.
Gdb starts up fine and the program loads OK and stops on the first breakpoint, which I set at the beginning main. Then when I type n to go to the next line, the program proceeds to run all the way through (as if I typed c), instead of going to the next line. To get around this, I set another breakpoint further down. After hitting c, (at the first breakpoint in main) the code skips to and stops at the latter breakpoint (which is what I want).
However, at this point, I can no longer enter gdb commands, as the source code has moved to the top window, and the output to the bottom window (whereas normally all the gdb input commands and program output occur in the top window, and the source code being traversed through on the bottom). So now at this point, when I enter gdb commands, it becomes part of the source code and I cannot navigate through it with n and c and such - instead the code has a bunch of n's an c's in it!
I'm running Fedora 18, and GNU Emacs 24.3.1. Also, to run gdb in emacs, it insists I use the switch -i=mi. After I hit M-x gdb, the line at the bottom pops up as: Run gdb (like this): gdb -i=mi .... I tried playing around with the switches, such as -annotate=3 to no avail.
If I understand correctly, you only have two windows open within emacs, and what has happened is that the output and source code buffers have replaced the gdb command buffer.
You can switch back to the gdb command buffer with C-x b *gud-programname* RET, where programname is the name of the program you are debugging. You might find it helpful to create a new window and switch to the gdb command buffer in that.
This happens because the gdb mode isn't clever enough to keep the command window on top. You can use M-x gdb-many-windows which improves on this a bit.
These two questions may also be helpful.
I want to find function in disassembly window using Ctrl+F by it's name (from symbols). How can I search through disassembly? Is there any extension?
I don't think searching is possible. However, you can:
1) jump to an address if you know it (e.g. 0x76EC0B28). Enter it in the Address field of the disassembly window.
2) jump to using mangled (decorated) name of the function (e.g. _GetProcAddress#8). Same as above.
3) add a breakpoint using the function name (New->Break at function... in the Breakpoints window), then use "Go to disassembly" from the context menu.
The last one possibly only works in VS2012 and above.
Is there a way in which I can debug my compiled Matlab components, using native Matlab debugger, like Visual Studio "Attach to process" option, or something like that?
I mean EXE stand-alone files, DLLs, COM in-process servers or .NET components.
You can't debug them in the sense of being able to step through the MATLAB code line by line, as you can with MATLAB's own debugger prior to compilation. One of the steps that the MATLAB deployment products take is to encrypt the MATLAB code (so you can preserve your IP when distributing the deployed component). The ability to step through the code in a debugger after deployment would defeat the purpose of that.
I experimented with using something like :
try
catch ME
waitbar(0,ME.message)
end
This was quite an effective and generic solution.
you may want to break down the code into multiple parts and debug each to save compiling time.
good luck,
dan
You can follow the instructions to debug:
Debugging:
Using the Debugging Tool will let you stop your program in mid-execution to examine the contents of variables and other things which can help you find mistakes in your program. M-file programs are stopped at "breakpoints". To create a breakpoint, simply press F12 and a red dot will appear next to the line where your cursor is. You can also click on the dash next to the line number on the left side of the M-file window to achieve the same result.
Then press F5 or Debug->Run from the menu to run the program. It will stop at the breakpoint with a green arrow next to it. You can then examine the contents of variables in the workspace, step, continue or stop your program using the Debug menu. To examine contents of a variable, simply type its name into the workspace, but be warned: you can only look at the values of variables in the file you stop in, so this means that you'll probably need multiple breakpoints to find the source of your problem. There are several different ways you can move through the program from a breakpoint. One way is to go through the whole program, line by line, entering every function that is called. This is effective if you don't know where the problem is. There's also a way to simply step through the function you're currently stopped in, one line at a time, and instead of going through the child functions line by line MATLAB will simply give you the results of those functions.
Finally, note that you cannot set a breakpoint until you save the M-file. If you change something, you must save before the breakpoint "notices" your changes. This situation is depicted in MATLAB by changing the dots from red to gray. Sometimes, you'll save but the dots will still be gray; this occurs when you have more than one breakpoint in multiple files. To get around this (which is really annoying), you have to keep going to "exit debug mode" until it turns gray. Once you're completely out of debug mode, your file will save and you'll be ready to start another round of debugging. Using comments to help you debug code. you want to test the effects of leaving out certain lines of code (to see, for example, if the program still returns Inf if you take them out), you can comment out the code. To do this, highlight it and then go to:
Text -> Comment
Or press CTRL+R. This will simply put a '%' in front of every line; if the line is already commented out it will put another '%' there so when you uncomment them the pattern of comment lines will not change. Commented lines will be ignored by the compiler, so the effect will be that the program is run without them.
To uncomment a line go to
Text -> Uncomment
Or press CTRL+T.
Another use of commenting is to test the difference between two different possible sets of code to do something (for example, you may want to test the effect of using ODE113 as opposed to ODE45 to solve a differential equation, so you'd have one line calling each). You can test the difference by commenting one out and running the program, then uncommenting that one and commenting the other one out, and calling the program again.
How to escape infinite loops?
MATLAB can't directly tell you you have an infinite loop, it does attempt to give you some hints. The first comes when you terminate the program. Terminate it by pressing CTRL+C and MATLAB will give you a message telling you exactly what line you stopped on. If your program is running a long time, it is likely the line you stopped in is in the middle of an infinite loop. sometimes MATLAB won't even let you return to the main window to press CTRL-C. In this case you probably have to kill the whole MATLAB process. After this, add a "pause (0.001)" or a similarly small value in the loop you suspect to be the infinite one. Whenever MATLAB passes this instruction you will be able to interact with MATLAB for a (very) short time, e.g. go to the main window and press CTRL-C with MATLAB being able to respond to your command.