Why is it that the breakpoint does not work?

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?

[Peng Li]

Did matlab stop anywhere before entering this function? Did you check the command window output? Any error message?

[alpedhuez]

Did not stop. Nothing on the command window. No error message.

[Sudheer Bhimireddy]

It would help if you could paste your code here.

[Adam Danz]

How are you invoking the live script file?

• Calling it directly from the editor (green "Run" button)
• Calling it from the command window
• Another function / script is invoking it

Does the live script show any warnings or errors within the file?

Have you tried closing the file and reopening it?

[alpedhuez]

"Run section." No warnings.

[alpedhuez]

Can I post the code so that you can take a look?

[alpedhuez]

It seems to me it is because I used parfor.

[Adam Danz]

Copy-paste the relevant sections into a comment.

[alpedhuez]

It does stop when I change from parfor to for.

[Raymond Norris]

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.

Answer 1

[Adam Danz]

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.

[alpedhuez]

breakpoints are red. it is a function within Livescript

[Adam Danz]

The advice in my answer pertains to live scripts as well.

[alpedhuez]

I think I checked all of the points mentioned...

[Steven Lord]

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

[Adam Danz]

Thanks, Steven!

Answer 2

[Steven Lord]

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."