Breakpoints unpredictable in R2011a
Show older comments
Since upgrading to R2011a, breakpoints in my code are unpredictable. Sometimes they work, and sometimes they don't. My code worked fine with breakpoints in R2010b. I don't have any "clear all" statements, and the breakpoints are still visible as red dots in my code. The code I'm using is on the MATLAB path, and there is only one copy.
Anyone else having difficulty with breakpoints in this latest release? Even better, anyone know how to fix it?
11 Comments
Manicka
on 10 May 2011
I'm also having the same problem. Breakpoints worked fine with 2010b, but in 2011a Matlab skips them about half the time and then I need to set breakpoints at other lines as well to get the original breakpoints to work.
Have you tried reinstalling?
TB
on 20 May 2011
I also have this problem. I am on Windows 7 x64.
Vladimir
on 8 Jun 2011
I am experiencing the same problem on Windows 7 x64. Same code, same workflow, but issue appears on 2011a and not 2010b.
SK
on 9 Jun 2011
Same problem here, also on Windows 7 x64. This problem did not appear before MATLAB R2011a.
Matan Hofree
on 25 Aug 2011
Same on Linux x64 (CentOS release 5.6 (Final))
Jan
on 25 Aug 2011
Did you ask the technical support already? What is the reply?
Daniel Shub
on 26 Aug 2011
Can you post some code and instructions on which line to place the break point so we can try and replicate your problem? I am running r2011a and do think I have this problem.
Friedrich
on 26 Aug 2011
This is a known issue and unfortunately not reproducible. MathWorks is currently investigating this further.
Daniel Shub
on 26 Aug 2011
Is there a bug report on this? I love the known bugs that are being investigate that are not listed as bugs.
Oleg Komarov
on 5 Sep 2011
This thing is starting to annoy me as well
What I do is:
click to clear > click to place the breakpoint back > save .m file
Richard Crozier
on 25 Apr 2012
This is frankly, outrageous, yet true!!
Accepted Answer
TB
on 21 Sep 2011
2 votes
The official word I got from The Mathworks is that it is fixed in R2011b, but no workaround for R2011a.
6 Comments
Jan
on 21 Sep 2011
Well, I do not like the method to fix bugs with new releases, because a new release will have new bugs and in consequence this strategy will not increase the total stability of Matlab. If I have to decide to buy a new Matlab version, I will not choose 2011a, because unpredictable breakpoints are very annoying. And I will not choose 2011b, because the currently unkown bugs might be even more annoying. And if the bugs are known, they will be fixed by choosing 2012a...
2010b, 2010a and 2009b had also serious bugs. I should buy an *old* Matlab version and choose 2009a. Not satisfying.
Daniel Shub
on 21 Sep 2011
@Jan, I totally agree. I wish MATLAB would do something like a LTS. Something like r2009a would have service packs r2009a_sp_r2009b, r2009a_sp_r2010a, ... where the service packs would only fix bugs and come with some really good documentation about what changed.
Friedrich
on 22 Sep 2011
EBR was created:
http://www.mathworks.com/support/bugreports/738717
Jan
on 22 Sep 2011
Fine, now it is a documented bug. Nevertheless it remains a bug and will not be fixed although it concerns the elementary functionality of MATLAB 2011a. This reduces the value of this release dramatically.
Robert
on 22 Sep 2011
Daniel Shub
on 22 Sep 2011
While I am all for venting and in my opinion it is fine to vent here, nobody who can do anything is listening (not quite, but you get the idea). Go through the official channel of customer support to let them know how you feel.
More Answers (5)
Alexander Kosenkov
on 31 Aug 2011
2 votes
Extremely annoying bug, since R2011a. Breakpoints have their own lives, regardless of user actions. Just doesn't work.
As workaround, sometimes, it helps to modify file (add and remove space) and then saving it again. Otherwise I have to restart Matlab (obviously loosing all breakpoints). Clicking 'Clear all breakpoints in all files' and then setting breakpoints again - does not help for me.
Anyone here from Mathworks to comment?
Andreas Goser
on 22 Sep 2011
2 votes
One user pointed me to this thread, as we were discussing aspects of the development timelines and fixing bugs. Indeed, MathWorks fixes bugs in the release under development and not by default for all affected older releases. But certainly, it is possible. And it happens. Please see the recent Service Pack releases. Those are responses on a number of (typically significant) bugs. In short, this is dependent on impact, frequeny and whether accpetable workarounds are available or not. I can just encourage you to describe the impact to Technical Support, so that they can provide this information to Development. You may think the impact is obvious? It is not.
3 Comments
Jan
on 22 Sep 2011
Thanks for this comment.
I see the problem of the efficient communication of bugs. It is a big challenge for the technical support to filter the high impact problems from the noise of "EVAL does not work as expected" messages. Sometimes the support team is a little bit stubborn (if this term has a negative connotation: sorry, meant more neutrally - I'm not a native speaker), but they *never* left me alone with a problem until I confirmed that it is solved.
I think, this forum is helpful to improve the communication with the technical support: a discussion with other users helps to reduce the noise. If the bug-report contains a rough overview about the number of affected users (e.g. "<10" "<100" etc) and a tiny description of the underlying cause of the bug, it would be easier to estimate, if this is a strange exception or a general lack or quality. "This bug was fixed as of R2011b(7.13)" is not a very encouraging feedback of the feedback.
Walter Roberson
on 22 Sep 2011
This is the first I have heard of the service pack releases ??
Jan
on 22 Sep 2011
@Walter: Go to http://en.wikipedia.org/wiki/MATLAB and look for the "Release history". There are 2 SPs sincs 2006.
Lucas García
on 31 Aug 2011
Hi Robert,
I haven't been able to reproduce this issue, but I have heard it from other users, so that makes it empirically a possible bug in R2011a. In any case, I will recommend that you report it to the Technical Support team mentioning your problem with as much detail as you can.
When you are debugging and type dbstatus, are the true breakpoint lines listed?
As a possible workaround, I will try the following:
>> feature accel off
>> feature jit off
1 Comment
Jan
on 22 Sep 2011
It cannot be called "workaround" to disable the JIT acceleration. Some of the loops will need 100 times more processing time, such that a program can become completely useless even if it only concerns the debugging.
Sean de Wolski
on 21 Apr 2011
0 votes
Are you calling it in cell mode by clicking "Evaluate Cell"?
6 Comments
Robert
on 21 Apr 2011
Sean de Wolski
on 21 Apr 2011
Okay. Do you have multiple files of the same name and it's not running the one you have. E.g. same named files in different folder in which case the break point containing one might not be running?
which your_mfile_name
Walter Roberson
on 21 Apr 2011
Also, is it possible that the file or directory is not writable? Breakpoints only work if the file is writable.
Robert
on 6 May 2011
Jan
on 8 Jun 2011
Any CLEAR ALL hidden in a subfunction?!
SK
on 9 Jun 2011
Definitely no CLEAR ALL in my code. And the file is writable, too.
Adam
on 2 May 2012
I didn't know this, maybe everyone else did...
The Matlab statement:
clear all
clears breakpoints. So if you have "clear all" in your script, any breakpoints after that line will be cleared before script execution reaches them, so Matlab won't break. Getting rid of this line was the solution in my case, but it may not work in every case.
[opinion] this functionality is DUMB and should be fixed. [/opinion]
Categories
Find more on Startup and Shutdown in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
