I am debugging a windows component and want to view all the functions of a particular dll that are called (also in the exact order they are called). I can do this by attaching the component to windbg and setting breakpoints over all the exported functions (bm *module_name!*) of the dll in question.
This works as expected. Whenever an exported function of that dll is called windbg breaks the execution and prints on the screen information about the breakpoint that is hit. After that I can manually resume execution by pressing F5 or giving the go command.
The problem:
Some functions of the dll have to return very quickly (immediately) else the component crashes. In that case the breakpoint causes the component to crash. I can remove the breakpoint in question but then there would be no log of it being hit.
I looked around and found that I can run a command whenever a breakpoint is hit. bm module_name!func_name ".printf \"func_name\n\";gc" But this is not feasible for every exported function. The dll has about a few 100 exported functions.
What can I do to log (on the screen itself) every exported function that is hit (even the breakpoint number would do if nothing else can be done). Is there a variable name I can use in the printf command that can print the function name (or the breakpoint number if not the function name)?
Figured it out. Thanks to EdChum.
The command: bm *module_name!* ".frame;gc"
Related
What is the difference between "step out (shift+F11)" and "continue (F)" in MATLAB debugger? When I debug a MATLAB function, both are triggering the cursor to come out of the loop. What is the exact difference between these two?
Continue (dbcont) will cause the program to resume execution and will only stop once it encounters another breakpoint.
Step-Out (dbstep out) will cause the currently executing function to continue and will automatically pause in the calling function regardless of whether you have a breakpoint there or not. Notice that this is referring to stepping out of a function and not a loop.
In your case, I'm assuming you only have a single function (or script) and therefore if you have no manual breakpoints after calling dbcont or dbstep out, they are going to have the same result since they will both just run the rest of the script to completion.
When I used older versions of MATLAB, I used to place breakpoints in any function that was called from the script/function I was running.
I've now moved to Matlab 2013, an now if I set a breakpoint inside a function that's called from my script, this breakpoint is ignored and disappears after the run - I must put a breakpoint in the call to the function in the script I'm executing, then step in, and then I can set breakpoints in the function I'm debugging. I know for sure that Matlab does executes the line I'm setting the breakpoint at (used debug prints).
Is there a way to change the preferences so that I could set the breakpoints not only in the executed script?
I wonder what the difference is between entering a few lines in the command window, or letting a script execute them.
In the question Escape from nested try - catch statement I have an example function. I have put the selected code in a script and called it, however then it does not work properly. On the other hand, when I
select the lines and hit f9, it works as expected.
The lines are:
dbclear all
dbquit
dbstop if caught error
I call the example function as such:
dbstop if caught error
mytestmain
And the example function is:
function mytestmain
try
mytestsub
catch
end
% Definition of subfunction, may or may not be in the same .m file
function mytestsub
try
a=b; %Intentionally generate an error as b is not defined
catch
end
I think it's related to MATLAB's just-in-time (JIT) compiler, which compiles functions before it runs them.
It seems that it compiles functions differently if dbstop is set or not (see here for reference). As it currently stands, MATLAB can not recompile a function while it is run (just try saving a changed function during a dbstop, and you will get a message informing you). As you can add and remove breakpoints during a dbstop I think you can also do so programmatically, but it should be impossible to "turn on" debugging if it wasn't turned on at "compile time"
So in your cases:
Using F9 it's just pasted and parsed as if you input it manually. So first dbstop is set, then mytestmain gets compiled and executed.
Running as a script will first compile the script and mytestmain and then execute it - so dbstop would be set after compilation and therefore not in effect.
Depending on what you mean by "doesn't work", it could just be because the debugger is a special context and certain debugger commands - dbup, dbdown, and dbquit - only work when you're at a debugger "K>>" prompt. Once you call a script, you're no longer at the debugger prompt but in normal code execution - inside a nested M-code call stack - and they just don't work there. When you F9, it does the lines individually, so each one is done from the prompt.
As a workaround, if you really want to execute a sequence of debugger commands like this, you could write a little Java Swing widget to enter the text in to the command window just as though you were typing it in.
I have used Eclipse and VS. When I insert a breakpoint and debug the program, it will stop before the breakpoint.
But what if I want to debug the effect of the last sentence of the program? Inserting a meaningless sentence(say print 'pause' in Python) is OK but seems awkward. Is there any alternatives?
In Visual Studio you can put break point on closing bracket in main (or any) method of Program (or any) class (default naming, may vary), then debugger stops just before closing application.
Is there any reason not to use a breakpoint on the last statement, like you said, then manually proceed one step? Depending on the debugger, this can also be automated. In GDB, one can use commands N, where N is the breakpoint number, to set a list of (debugger) commands to be executed immediately after a breakpoint is hit.
Is there any command using which we can inspect a object in command line while app is running in DEBUG mode. I do not want to put description message in the code.
Try these resources. one two
(gdb) p varName
Yes sure. If you are debuging, breakpoints are automatically set to on. Just set a breakpoint to the line in which the variable is. The program stops as soon it reaches the line with the breakpoint. Just hold the cursor over the variable and all important data is displayed. I do it also that way all the time. ;-)