Thread Subject:

Breakpoints not visible in editor

I have been having the following curious issue with Matlab's debug mode recently. I typically use the debugger heavily -- usually by setting breakpoints on individual lines in the Editor window, resulting in the normal red-circle image denoting a line with a breakpoint on it.

For the past few days, I have been unable to get these breakpoints to visible show up. I click a line and the red circle partially shows up (as I am holding the mouse click) and then disappears. However, the breakpoint is active, as checked by either dbstatus or by simply running the code. When execution breaks at the line and the program pauses, I have no visual confirmation that it is paused at that line (i.e. the typical arrow pointer in the Editor window) except for the status message saying I am in debug mode.

There are no uses of clear or clear all in the code, but I want to re-emphasize that the breakpoints are not inactive, they are simply not visible.

Thanks

On 11-02-24 01:41 PM, Scott wrote:
> I have been having the following curious issue with Matlab's debug mode
> recently. I typically use the debugger heavily -- usually by setting
> breakpoints on individual lines in the Editor window, resulting in the normal
> red-circle image denoting a line with a breakpoint on it.
> For the past few days, I have been unable to get these breakpoints to visible
> show up. I click a line and the red circle partially shows up (as I am holding
> the mouse click) and then disappears. However, the breakpoint is active, as
> checked by either dbstatus or by simply running the code. When execution
> breaks at the line and the program pauses, I have no visual confirmation that
> it is paused at that line (i.e. the typical arrow pointer in the Editor
> window) except for the status message saying I am in debug mode.
> There are no uses of clear or clear all in the code, but I want to
> re-emphasize that the breakpoints are not inactive, they are simply not visible.

People have seen similar effects before. If I recall correctly, for some of
them, quitting and restarting Matlab worked. For others of them, it had to do
with a file or directory not being writeable -- though I would have _expected_
that in that case it would refuse to set the breakpoint at all according to
dbstatus.

Scott:
It could be that your m-file is running. For example, let's say this
is your code:

clc; % Clear command window.
workspace; % Make sure the workspace panel is showing.
a = 73;
uiwait(msgbox('Waiting for you . . .'));
b = 42;

You run it and the message box comes up, but if, instead of
interacting with the message box, you go to the editor and try to set
another breakpoint, you'll get the behavior you described.
ImageAnalyst

"Think two, count blue." <roberson@hushmail.com> wrote in message
> People have seen similar effects before. If I recall correctly, for some of
> them, quitting and restarting Matlab worked. For others of them, it had to do
> with a file or directory not being writeable -- though I would have _expected_
> that in that case it would refuse to set the breakpoint at all according to
> dbstatus.

Thanks for the response. I naturally tried a good old fashioned restart without success. Even a reinstall and reset of the $HOME/.matlab settings directory did not alter the breakpoint behavior. I could understand this being a Java issue but have been unsuccessful with finding any notable mention of it on other forum threads. Can you point me toward the discussions you are mentioning, either direct links or even just terms to search with?

On Feb 24, 5:43 pm, ImageAnalyst <imageanal...@mailinator.com> wrote:
> Scott:
> It could be that your m-file is running.  For example, let's say this
> is your code:
>
> clc;    % Clear command window.
> workspace;      % Make sure the workspace panel is showing.
> a = 73;
> uiwait(msgbox('Waiting for you . . .'));
> b = 42;
>
> You run it and the message box comes up, but if, instead of
> interacting with the message box, you go to the editor and try to set
> another breakpoint, you'll get the behavior you described.
> ImageAnalyst

----------------------------------------
Are you saying that it happens immediately after you start MATLAB,
even before you try to run anything (like I guessed)?

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <a37d3f6e-9694-4e8b-bc1e-77af31fd8dc6@18g2000prd.googlegroups.com>...
> Scott:
> It could be that your m-file is running. <snip>

I see where that could complicate the issue, but whatever I am dealing with is much more basic. I can reproduce the problem by creating a new m-file (any old function seems to work, but I've reproduced the most basic one here) and trying to set a breakpoint on either the second or third line of the function. Either one is set, as checked by dbstatus or running the program and seeing execution pause and the debugger be entered, but there is no visible breakpoint.

function res = exampleFunction(x)
    res = 2*x;
end

Since I didn't explicitly mention this beforehand, I suppose it's worth pointing out that nothing changes if I attempt to set the breakpoint via the command window, using dbstop -- the breakpoint is set and can be used but there is no visual cue for its location, and no visual cue for the actual paused status of the debugger, i.e. what line execution is paused at. All other behavior of the debugger seems normal, including full access to variables, tool-tips on variable mouseover, etc.

Did you save your file yet? Because you're not allowed to set a breakpoint unless the file can be saved. If you haven't saved it yet, or are not allowed to for some reason, you won't get the red spot.

On 11-02-24 05:29 PM, Image Analyst wrote:
> Did you save your file yet? Because you're not allowed to set a breakpoint
> unless the file can be saved. If you haven't saved it yet, or are not allowed
> to for some reason, you won't get the red spot.

If you haven't saved the file yet, but _can_ save the file, then you get a
grey spot where the breakpoint will go once you have saved the file. This is
the same behaviour as for modifying a file.

(I have not made any tests with files or directories I do not have write
permission for.)

I both can, and have, saved the file. Keep in mind, the breakpoint mechanism must be working because I can debug/step/continue as I normally would be able to. The only difference is the lack of visual cues like the red circle or the arrow indicating the current line of execution.

The grey circle is happy to appear if I have unsaved changes, but as soon as I save the file I am unable to see any breakpoints set or any visual indication when the debugger pauses execution.

I'd call the Mathworks about it. But one last thing to try. Do you
have the latest Java update? Go to control panel and make sure. If
you already have the latest Java update, then did the problem suddenly
start occurring after a Java update perhaps?

I second ImageAnalyst about calling TMW about this.

In addition, here's another wild thought: breakpoints are known to be correlated to the pwd and the path (i.e., cannot set a breakpoint if not on path etc.) - so perhaps something has changed with your path and/or pwd that you can reset. For example, try cd()-ing to another folder and debugging a simple m-file there.

Another wild thought: rename your prefdir() folder to something else and restart Matlab - this should start a fresh Matlab with no possibly-tainted memory of a bad preference somewhere (Matlab should create a new clean prefdir). If this works, then start copying files from the renamed (previous) prefdir to the new (clean) prefdir, until you find the culprit file. It could take some time, but it's all very straight-forward.

Yair Altman
http://UndocumentedMatlab.com

"Yair Altman" wrote in message <ik8cqo$5ch$1@fred.mathworks.com>...
> In addition, here's another wild thought: breakpoints are known to be correlated to the pwd and the path (i.e., cannot set a breakpoint if not on path etc.) - so perhaps something has changed with your path and/or pwd that you can reset. For example, try cd()-ing to another folder and debugging a simple m-file there.
>


Ah, now we have some progress! On a hunch, I tested whether breakpoints work in a new directory tree and they do. Here's the setup:

$HOME/research/manysubdirs

Now when I make any subdirectory of research Matlab's current directory, the "Current Directory" bar in Matlab has the correct path, except "research" has a capital R instead of a lowercase r. This is an issue I have noticed for a while but am unsure how to reverse since I don't actually know what is causing the mismatch between what Matlab says and the actual folder name.

I have tried clearing the contents of my prefdirs directory, but this behavior does not change. If I am working in a file outside the research branch, breakpoints work fine so it appears to be caused by the mismatch between what Matlab thinks is the path and the actual one in the filesystem.

Horrible working solution: never work in this subdirectory again =)

Just had an occurrence of this myself under 2008a. I could only get the breakpoint to be visible if working dir was dir where code lived.

My problem was I had done this in my startup:

dir_stub = '.';

and then

addpath( fullfile( top_most_dir, dir_stub ));

where top_most_dir is parent directory in my tree of MATLAB code directories.

This had the effect of doing:

which no_breakpoints.m

$top_most_dir\.\no_breakpoints.m

That was a problem for some reason. So I just changed dir_stub to be '' (empty string)

and now the which call gives

$top_most_dir\no_breakpoints.m

and I can get my visible breakpoints.

(In reality dir_stub is a list of directories that I cycle through one-by-one doing existence checks before addpath calls - it used to be [still is?] that addpath took a disastrous amount of time to fail to add a non-existent path whereas exist can tell you instantly that a path does not exist, helpful when code lives in occasionally failing networked drives.)

"Scott " <deletethis.striglia@uci.edu> wrote in message <ik6c8l$616$1@fred.mathworks.com>...
> I have been having the following curious issue with Matlab's debug mode recently. I typically use the debugger heavily -- usually by setting breakpoints on individual lines in the Editor window, resulting in the normal red-circle image denoting a line with a breakpoint on it.
>
> For the past few days, I have been unable to get these breakpoints to visible show up. I click a line and the red circle partially shows up (as I am holding the mouse click) and then disappears. However, the breakpoint is active, as checked by either dbstatus or by simply running the code. When execution breaks at the line and the program pauses, I have no visual confirmation that it is paused at that line (i.e. the typical arrow pointer in the Editor window) except for the status message saying I am in debug mode.
>
> There are no uses of clear or clear all in the code, but I want to re-emphasize that the breakpoints are not inactive, they are simply not visible.
>
> Thanks

lol one of us is going to have to change our nick. I'll go change mine otherwise you will be credited with my silly inane posts and I will be credited with your brilliant posts eheh. I'll add my lastname intial to the end of my nick.

Cheers,
Scott...erm ScottB. :)

"Scott " <deletethis.striglia@uci.edu> wrote in message <ik8tds$ac7$1@fred.mathworks.com>...
> "Yair Altman" wrote in message <ik8cqo$5ch$1@fred.mathworks.com>...
> > In addition, here's another wild thought: breakpoints are known to be correlated to the pwd and the path (i.e., cannot set a breakpoint if not on path etc.) - so perhaps something has changed with your path and/or pwd that you can reset. For example, try cd()-ing to another folder and debugging a simple m-file there.
> >
>
>
> Ah, now we have some progress! On a hunch, I tested whether breakpoints work in a new directory tree and they do. Here's the setup:
>
> $HOME/research/manysubdirs
>
> Now when I make any subdirectory of research Matlab's current directory, the "Current Directory" bar in Matlab has the correct path, except "research" has a capital R instead of a lowercase r. This is an issue I have noticed for a while but am unsure how to reverse since I don't actually know what is causing the mismatch between what Matlab says and the actual folder name.
>
> I have tried clearing the contents of my prefdirs directory, but this behavior does not change. If I am working in a file outside the research branch, breakpoints work fine so it appears to be caused by the mismatch between what Matlab thinks is the path and the actual one in the filesystem.
>
> Horrible working solution: never work in this subdirectory again =)

I have just noticed this problem began occurring on my machine (Windows XP) after a rebuild and installation of R2011a. However, I do not appear to have the mismatch between the working directory and what Matlab thinks is the working directory that Scott references above. Any further progress on why this occurs and how to stop it?

Look for "." in your path. That was my problem and fixed by removing it (see above post).