MATLAB bug when adding new function while on breakpoint?

My program takes a bit of time to load in variables and files, so I prefer to set a breakpoint and test run functions by pressing F9 (run line of code) while highlighting the function in the script.

Here's what happened:

Function A has the breakpoint (program paused execution)

Function B has the code I want to change/test by plotting data and changing it as needed

Function C is the new function (`edit funcC`) while breakpoint paused in function A

Function B calls for Function C to run

Function B & C successfully saved to disk (no changes made to Function A)

Function B called (highlighted and pressed F9) while on breakpoint in Function A

I subsequently got an error stating that Function C does not exist.

My Solution:

Terminate the process for Function A

Move current directory up one folder

Move back into directory with functions and rerun program

Worked fine after that.

It's a minor inconvenience with an easy solution, but could this be a bug and can it be fixed soon to improve MATLAB? I am using R2017a commercial edition.

[Stephen23]

Do you use cd anywhere in your code? Or any operations that change the path?

[Tyler Warner]

No, the directory remains the same.

Answer 1

[Jan]

The debugger is thought for (guess what?) debugging. It is not a powerful tool to control the program flow. Maybe the observed behavior is a but, or it is intended. Modifying code during the the program runs, can have extremely strange side-effects, e.g. if a function calls itself recursively over a certain number of other functions. There is no chance to cope with such ambiguities reliably.

In addition, enabling the debugger (e.g. by setting breakpoints) disables the JIT acceleration. This is required, because the JIT can reorder the sequence of commands to improve the speed. But then stepping through the code line by line cannot work anymore. In consequence some code can be 100 times slower compared to a disabled debugger. Therefore it is a bad idea to use the debugger to modify the code while the program is running.

There are smarter and more efficient techniques, e.g. load the data into a persistent variable:

function Data = Storage
persistent Data_P
if isempty(Data_P)
  Data_P = load(...)  % The long part to initialize the data
end
Data = Data_P;
end

Then you can call this function to obtain the data, but they are kept in the memory and the following calls will run much faster. This is much cleaner and more reliable than juggling with the debugger.

So my advice is not to use the debugger to control the program flow. Use code and persistently stored data to do this.

[Tyler Warner]

Thanks! I didn't know about persistent variables until now.

[Steven Lord]

Another possibility that avoids persistent variables (the clearing of which requires adding more code to your function specifically to manage the variable, or requires clearing your entire function) would be to accept the data as an additional input argument. As long as you don't try to modify that data inside your function, the copy-on-write behavior of MATLAB should prevent making a copy.

If you have limitations on what the signatures of your functions need to be, you can use one of the techniques on this page to satisfy the requirements of your function (accepting the additional data) and your function's caller (the restriction on the signature.)

[Tyler Warner]

That also works, thank you!