I wrote a custom debugger as described in perldebguts. There's something wrong with my debugger code, though, so I want to step through my DB::DB() and DB::sub() routines line-by-line to isolate the problem.
I suppose I can do this by setting $^D to 1<<30, since the documentation says:
When the execution of your program reaches a point that can hold a breakpoint, the DB::DB() subroutine is called if any of the variables $DB::trace, $DB::single, or $DB::signal is true. These variables are not localizable. This feature is disabled when executing inside DB::DB(), including functions called from it unless $^D & (1<<30) is true.
When execution of the program reaches a subroutine call, a call to &DB::sub (args) is made instead, with $DB::sub holding the name of the called subroutine. (This doesn't happen if the subroutine was compiled in the DB package.)
(emphasis added)
People on the IRC #perl-help channel said that with $^D & (1<<30) I may be able to debug my debugger but they didn't know any details beyond that.
How can I trace the execution of my DB::DB() and DB::sub() subroutines step-by-step?
UPD
According to the answer below. When set $^D |= (1<<30) flag this allows me to debug debugger commands which is defined outside of DB namespace, but that is not an answer for question: How to disable that feature when executing inside DB::DB?
This is my custom debugger Devel::DebugHooks which I want to debug.
When I run this expression from debugger $^D|=(1<<30) and after that run debugger command, like vars 2 $x, this will allow me to debug code which is called from DB:: namespace.
This feature is disabled when executing inside DB::DB(), including functions called from it unless $^D & (1<<30) is true
This sentence from DOC just makes confusion.
The feature is NOT disabled when executing inside DB::DB() unless $^D & (1<<30) is true.
This feature is disabled only for functions called from DB::DB() when $^D & (1<<30) is true
Related
I am using emacs for programming, and recently also gdb.
The "locals" window does show local variables but not arguments to a function, which in a way also could be considered local variables. For example, if I have
void foo(char *bar)
{
int n;
....
}
then n is shown in the "locals" but not bar. Of course, I can print bar but it is not automatically updated while I step through the code and I have to print all the time.
Is there a way to add expressions that are shown in a window and constantly updated as I execute the code?
The display command will certainly fulfill your needs:
If you find that you want to print the value of an expression frequently (to see how it changes), you might want to add it to the
automatic display list so that GDB prints its value each time your
program stops.
By example, once that your are in foo body (under gdb), type:
display bar
The interactive command gud-watch will watch the expression at point and display its value in the speedbar. Prefix it with C-u to be able to enter an expression.
See the manual page Watch Expressions for more details.
At the moment there doesn't seem to be a way to display watched expressions in the locals window.
Is there a way to retrieve the output of a function that did not complete properly?
For instance, a (non global) variable that was correctly computed by a function but that couldn't be saved properly because of syntax errors.
In principle, you can't look into a function once the program has stopped with an error. (That's why I often try to avoid functions.)
However, you can achieve what you want by entering debugging mode, using the dbstop function to set a breakpoint:
The dbstop function is used to temporarily stop the execution of a
program and give the user an opportunity to examine the local
workspace.
In particular, typing
dbstop if error
in the command window before running your code will make it stop at the point that caused the error and look at the variables within that function.
To restore normal behaviour you need the dbclear function. Type
dbclear if error
to remove the previously set breakpoint, or
dbclear all
to remove all breakpoints.
As stated in MATLAB's FAQ,
1.3.3.1. Why, when I edit a function file in MATLAB, is the change not seen by MATLAB until everything is cleared or MATLAB is restarted?
When you write an M-file in MATLAB, you can either write a script or a
function. The difference is that a script is read from the disk and
parsed line by line each time it is called. A function is loaded into
RAM for execution. Because it is loaded into RAM, when you edit a
function, that change is not loaded into RAM until a call to the new
function is made.
To get MATLAB to recognize your edited function, type
clear functions to clear all functions, or
clear <function name> to clear just your function out of RAM.
This is a major pain when I'm developing a function & editing it repeatedly (I use an external editor most of the time). I was thinking of putting in a final line, at least during debug, like
clear(myfunc)
but I'm concerned about unwanted side effects. Does anyone know if there are any?
Further, I'd rather have a way to configure MATLAB so it doesn't automatically store called functions in RAM once the top-level function (i.e. the one called from the console) terminates. Is that even possible?
EDIT: I should mention that MATLAB's behavior is inconsistent. Sometimes my edits take effect once I save the m-file, other times they don't even if I'm editing with the MATLAB IDE editor window.
In all honesty MATLAB has a very powerful editor so you really should
be using it. It will make you life easier. (just an opinion)
Unless you are running the code by stepping through it no change to code will be run until the code is re-run (preferably with a cleared workspace).
clear(myfunc) will clear the variables created by that function in upto that point. You can add at the end of any function or script clear variableA variableB for all variables you want cleared at the end. This will give you control to only clear what you want. Once variables are cleared the only effect will be that if those variables are called again later in the code an error will occur since they no longer exist.
If your simply testing that particular function and want to save time by not calling inputs each time and want to clear the workspace and command window at the same time. You can add the following code just beneath the function definition.
If you leave the following code and call the function from another function or script, the code will be ignored as long as the inputs are available to it externally. Anything you add to the if statement will only occur when you call the function with no inputs doc nargin. You could add it to the top level function and you would simply press the run button or f5 without having to type in the command window to run the code.
function [ output1, output2 ] = blah( input1, input2 )
if nargin == 0
clc
clear all
%above two lines will clear the workspace and command window when you run
%the function
%define function inputs
%(optionally add the following to behave as if you inserted a breakpoint
%in the location just before the error occurred (great for debugging)
db stop if error
end
*you can also add a short-cut to snippets of code up in the top right of the MATLAB interface to clear the workspace etc when they are clicked.
Hackish* idea for this:
I'd rather have a way to configure MATLAB so it doesn't automatically store called functions in RAM once the top-level function (i.e. the one called from the console) terminates. Is that even possible?
* This is the sort of thing I might use, while advising others on why it is a bad idea, also probably uses undocumented (thus unreliable) things.
Specifically if your using an external editor I guess your going to have to click on the command window to run the function...
commandWindowHandle = ...
handle(com.mathworks.mde.desk.MLDesktop.getInstance.getClient('Command Window'...
.getComponent(0).getComponent(0).getComponent(0),'CallbackProperties');
commandWindowHandle.MouseClickedCallback = 'clear functions'
It doesn't clear the function definitions on exiting a function rather on clicking on the command window
note: the callback will not fire if a function is currently running
For a potentially more reliable but more wasteful version:
commandWindowHandle.KeyPressedCallback= 'clear functions'
will help* ensure definitions are clear, but is wasteful as every keystroke will run 'clear functions'... although after one keystroke this will be quicker as there will be no functions in memory!
* No guarantee I know there are ways in which this could fail... having at least 1 keystroke in the command window after the previous function call has finished would be advisable!
To disable these set the callback to empty string ''
commandWindowHandle.MouseClickedCallback = ''
commandWindowHandle.KeyPressedCallback= ''
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"
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.