Why is it that the breakpoint does not work?

142 views (last 30 days)
I define some function. I set a breakpoint in the first line after the function definition statement. But when I run the program the program does not stop at the breakpoint. Why?
  10 Comments
alpedhuez
alpedhuez on 5 Aug 2020
It does stop when I change from parfor to for.
Raymond Norris
Raymond Norris on 5 Aug 2020
The debugger won't stop in parallel code. Imagine you have a pool of 4 workers and you want to stop on the "c" assignment.
c = 0;
parfor idx = 1:16
A(idx) = rand;
b(idx) = myfcn;
c = c + rand;
end
Where is the breakpoint? For starters, it's not on the MATLAB client because the code is (mostly) running on the workers. But which worker? You have 4 running, all at the same time. So now you'll have 4 breakpoints. This would require a parallel debugger, which MATLAB doesn't have. It's also why when you reverted back to a for loop it worked.
It's best to ensure that the for loop works with out issue (try running your for loop backwards, do you get the same answer) and that you address any Code Analyzer suggestions.

Sign in to comment.

Accepted Answer

Adam Danz
Adam Danz on 5 Aug 2020
Edited: Adam Danz on 5 Aug 2020
First, make sure the breakpoint is valid. Invalid break points are gray, valid break points are red. For more info, see "invalid breakpoints". Common causes of invalid break points are
  • adding a break point while running debug mode after editing the file
  • when a syntax error is within the file
Second, make sure the function file that contains the break point is the function file being invoked during execution. If you have two functions with the same name on your Matlab path, it could be the case that the function Matlab is invoking is a different function from the one you're editing. Run
which myFunction % replace myFunction with your function name
to determine if the output matches the path to the file you're editing. If not, use addpath() to add the correct file path or rename one of the functions/files.
Third (perhaps this should be 1st), double check that you're calling the correct file. If the file is being called directly from the command window, check for typos. If the function is being called from within another function, put a break point within the caller function at the line that calls your function and then press F11 to step into whatever function Matlab is invoking.
  5 Comments
Steven Lord
Steven Lord on 5 Aug 2020
Using which is good, but that still may not show the exact function being executed. For example, consider the sin function. There is a built-in function named sin, but that built-in is not used when the input is a sym object. The sym class has its own overload of sin. If you use the technique shown in the "Locate Function Invoked with Given Input Arguments" example on the documentation page for which, it can show you which overload gets called. [I manually replaced the matlabroot path in the output below with $MATLABROOT.]
>> syms x
>> which sin
built-in ($MATLABROOT\toolbox\matlab\elfun\@double\sin) % double method
>> which sin(x)
$MATLABROOT\toolbox\symbolic\symbolic\@sym\sin.m % sym method
>> y = sin(x); % Calls the sym method, not the double method

Sign in to comment.

More Answers (1)

Steven Lord
Steven Lord on 5 Aug 2020
The body of a parfor generally doesn't run in the MATLAB session in which you're running the parfor. As stated in the "Test parfor-Loops by Switching Between Parallel and Serial Execution" example on the documentation page for parfor, "This is the simplest way to allow you to debug the contents of a parfor-loop. You cannot set breakpoints directly in the body of the parfor-loop, but you can set breakpoints in functions called from the body of the parfor-loop."

Categories

Find more on Matrices and Arrays in Help Center and File Exchange

Tags

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!