Breakpoint is cleared w/o using "clear all"

13 Ansichten (letzte 30 Tage)
mary
mary am 21 Aug. 2014
Kommentiert: DrLoz am 12 Apr. 2017
Hello,
I am using MATLAB R2014a, 64 bit. Recently I often have troubles using breakpoints. It happens, I set a breakpoint somewhere in a function and when I call this function, MATLAB does not stop at the breakpoint, but runs further. When I then stop the execution and check the breakpoint it is gone. I am aware of the fact that "clear all" clears breakpoints as well. So I always make sure, there is no "clear all" somewhere. Sometimes it helps to close MATLAB and re-start it.
Thanks for any advice,
BG
  3 Kommentare
Sean de Wolski
Sean de Wolski am 24 Jun. 2015
Morten, are they grayed out until you add/remove space? There was a setting that changed in 14b I believe that now automatically saves files, but it does not do this if you're in debug mode. I've seen this happen a few times there where the breakpoints are there but disabled because the file is not saved.
DrLoz
DrLoz am 12 Apr. 2017
Re starting matlab is what I do to fix the "feature" (bug) unfortunately. Not ideal but it works

Melden Sie sich an, um zu kommentieren.

Antworten (4)

Sean de Wolski
Sean de Wolski am 21 Aug. 2014
Bearbeitet: Sean de Wolski am 21 Aug. 2014
My guess is you are unknowingly calling clear all or possibly dbclear all :(.
To find out, one thing you can do is overload clear temporarily and put a break point in it.
function clear(varargin)
dbstop in clear at 3
1;
1;
end
Now the debugger will stop in this clear when it's called and you can look at the call stack to see where the offending clear all came from. Be sure to rename or delete this file afterward.
The other thing that could be happening is that the file could be getting removed from the path (changing directories or explicitly modifying the path). This can clear it's breakpoints as well.
  2 Kommentare
mary
mary am 21 Aug. 2014
Bearbeitet: mary am 21 Aug. 2014
Thanks for your answer! I am quite sure, it is not a "clear all" or even a "dbclear all" issue. The file is not moved from the path either, I guess, since everything is still running, but just not stopping at the breakpoint. And I am also sure, the part of the code, where I set the breakpoint is actually executed. Nevertheless I will overwrite the clear function, as you suggested, the next time I am running into this. Unfortunately it is not reproduceable.
Sean de Wolski
Sean de Wolski am 21 Aug. 2014
A workaround is to use "dbstop in file at line" in the code like I did above. That way, even if the breakpoint is cleared, it will be re-instantiated at that line.

Melden Sie sich an, um zu kommentieren.


Image Analyst
Image Analyst am 21 Aug. 2014
"clear all" does not clear breakpoints, despite what the documentation erroneously says. Just try it in a simple 2 or 3 line script to prove it to yourself.
My guess at what you're seeing is an undocumented "feature" in GUIDE. If you're using GUIDE to create your GUI, and then save some small change you made, then it will remove all breakpoints that you've set up in your m-file. If you're running from GUIDE, rather than MATLAB, it may save automatically. Another annoying feature is that saving from GUIDE also removes any bookmarks you've set in the file you're saving.
There is another case where it won't stop at your breakpoints and that is when you set breakpoints in a GUIDE-generated function that gets called from your first function. Like you set a breakpoint in the OpeningFcn of fun2, and you run fun1 which calls fun2. It won't stop at the breakpoint in fun2. Mathworks knows about that feature/bug. Not sure if it has been fixed in R2014 yet - I haven't checked.
  8 Kommentare
mary
mary am 22 Aug. 2014
Thanks for the answers and comments! I do not use GUIDE. Nevertheless, I fear, I am bothered by a bug.
Image Analyst
Image Analyst am 22 Aug. 2014
Is it possible that you're running one m-file, and then after mfile1 is running, you go into the editor and set a breakpoint in mfile2 that mfile1 calls? Because that's another situation where it might not stop at the breakpoint. It seems you have to save any mfile where you set a breakpoint unless you're running and in it already. For example if you stopped at a breakpoint in mfile1 you could set another breakpoint in mfile1 without saving it, but it won't stop at any breakpoints in mfile2 unless mfile2 is saved (and I'm not sure it will do any good to save mfile2 after mfile1 has started running, it might have to be saved before mfile1 starts - I'd have to check on that).

Melden Sie sich an, um zu kommentieren.


per isakson
per isakson am 22 Aug. 2014
Bearbeitet: per isakson am 17 Jun. 2016
I believe that you are seeing a bug in Matlab.
I experience problems with breakpoints on a regular basis (in R2013a and older releases). Restart of Matlab is the only remedy, (that I found). I have never been able to reproduce the problem such that it is meaningful to report to tech-support.
If I ignore this behavior and continue to use Matlab there is risk that Matlab eventually crashes.
PS. I never use GUIDE.
  4 Kommentare
per isakson
per isakson am 23 Aug. 2014
Bearbeitet: per isakson am 23 Aug. 2014
"MATLAB is likely to crash" &nbsp No, I didn't mean to convey that meaning. I deleted the word "significant" in "significant risk".
Nearly all my unexplained crashes occur when I'm debugging and very often they are preceded by malfunctioning breakpoints. Such crashes may occur once a month or something, depending on whether I listen to the warnings or not.
Yair Altman
Yair Altman am 4 Sep. 2014
I envy you per - I crash or hang Matlab several times a day...
Then again, I'm not known for working with run-of-the-mill code... :-)

Melden Sie sich an, um zu kommentieren.


Aaron Thrasher
Aaron Thrasher am 16 Jun. 2016
I know this is an old post, but as I see that there are still recent viewers I figured its worth sharing.
I am running on 14b and I experience this issue on a constant basis. I recently spent some time investigating it on my own and I have found a quick and easy solution. If you close and reopen the file in the editor window, the problem goes away. This suggests that somewhere Matlab does not think it is saved for whatever reason. Clearing the break point is probably a safety measure built in. I'm thinking the bug exists within the method of saving the m-file that instead of turning a grey dot red it doesn't do anything, but this means it doesn't update its underlying skip break point action. Since saving has to do with the .asv file, closing the m-file in the editor clears this file. I've tried to implicitly reproduce the error and not been successful, but I hope this helps people experiencing the issue and Matlab to find the bug if it hasn't already been found in later versions of matlab already.
  2 Kommentare
Ray Maynard
Ray Maynard am 14 Okt. 2016
Thanks Aaron, tried this in 2014b but no luck, still ran but ignored the breakpoint. I did notice though, that it acknowledges the breakpoints when I do a full run (f5) whereas it ignores them when I run sections (ctrl + enter). Maybe there's something to that, in combination with what you mentioned.
Steven Lord
Steven Lord am 14 Okt. 2016
That's expected behavior; see Sean's answer in this message.

Melden Sie sich an, um zu kommentieren.

Kategorien

Mehr zu Debugging and Analysis finden Sie in Help Center und File Exchange

Community Treasure Hunt

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

Start Hunting!

Translated by