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.
Related
I have encountered a weird situation recently: when I am running my programs, sometimes the execution pauses when it reaches some warning statements (yet, sometimes it doesn't stop in identical situations, and just outputs the warning statement). I cant force the program not to stop. when I click on the small triangle below the "run" or "Breakpoints" in the editor "stop on warning" is sometimes checked, If I remove its tick, it becomes checked again after a while and the program stops on some warnings!
Has anybody encountered similar issue? is there a way to force the program not stop (maybe using some code)
Programmatically, you can use dbstop and dbclear to set and clear break conditions.
In your case, use dbclear if warning.
And see https://www.mathworks.com/help/matlab/ref/dbclear.html
What is the difference between "Step" and "Step in" in the MATLAB debugger? As far as I have tested them in some debugging so far they gave me the same steps and results.
When you use step in on a function call, you will enter said function. step is used to move to the next line. When you use them on lines without function calls, they are equivalent.
The command dbstep (or the debugger tool "Step") executes the next line of code. It does not stop within that function, even if that function is implemented in MATLAB code and contains breakpoints.
The command dbstep in (or the debugger tool "Step In") also executes the next line of code, but if that line is a call to a function implemented in MATLAB code (i.e. not a built-in), it will enter that function and stop at the next line of code within the function.
If the next line is not a call to a function implemented in MATLAB code, dbstep and dbstep in are equivalent.
See the Matlab doc: dbstep
Basically, Step executes the next line, even if there is a call to complex function/other script. Step In jumps in the code on the called function if possible, else executes the entire line.
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.
My question is, how do I stop a script by a pressing a GUI button? I already tried to write a code that simulates "CTRL+C" press, but it doesn't work.
I'm not sure there's a way to stop another script from being called. One alternative would be to set a global variable that's periodically checked by the script you wish to stop. If you set the value of a "stop processing" variable to true in your callback, the other script could stop if it found that it was supposed to stop.
Edit
If you'd like to have a GUI option to stop an ongoing process, I would recommend you take a look at something like STOPLOOP on the MATLAB File Exchange.
I won't write the code for you but here's a high-level way to accomplish this:
Display a waitbar with a button on it. Create a callback function for the button which sets a flag to true.
Begin computation inside of a for-loop. In the loop:
1. update the waitbar.
2. call the drawnow function so that the callback is executed properly. Remember MATLAB is single-threaded, so this is necessary or the callback will not execute until the script finishes.
3. perform any other computation
4. check for the flag set to true. if it is true, return to stop execution.
The flag could be a global variable, or a handle-based object (so that it is passed by reference).
EDIT:
This answer is not applicable for the current question.
This answer is applicable only for scripts having the first line = #!/usr/bin/matlab
use pkill without option will send a TERM signal:
pkill yourscriptname
If you really want the same signal as CTRL+C then:
pkill -3 yourscriptname
If your script still does not stop, you can use the most aggressive signal KILL:
pkill -9 yourscriptname
Of course, if you known the PID (Process IDentifier), you can simply use kill:
kill yourPID
kill -3 yourPID
kill -9 yourPID
You can have more info about signals using one of these commands:
man 7 signal
kill -l
info signal
I don't do a lot of GUIs, but for debugging purposes I would try to set the button callback to #keyboard. That is, something like:
set(handleToGuiButton,'Callback',#keyboard)
To actually stop execution you would need to somehow communicate this button press into the loop that was executing, for example via global variables, or something fancier (e.g. https://stackoverflow.com/a/8537460/931379)
But I would honestly look at the stoploop link (from another answer) before going down any of these routes.
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.