dbquit (or click "quit debugging") doesn't always seem to exit debugmode?

Hi All,

I've seen this behavior, actually, my entire matlabbing live, but i've never thought about it twice until today (because it became a bit annoying).

Sometimes, when I'm debugging, and want to exit debugmode, it doesn't exit debugmode immediately when giving dbquit command. I think this probably has to do with debugging in nested functions or executing other commands in between, and the dbstop command being turned on? I'm not sure.

However, on some occassions, I really have to execute dbquit about ten or more times ('arrow up, enter, arrow up, arrow up, enter). This has happened to me on many occassions.

Today, this seemed to happen while it stopped in debugmode on a particularly line that takes a sec's to compute (input parsing). I noticed that, when trying to exit debugmode, it takes a while before it stops being "busy" and is again in debug mode, approximatly the same time this line would normally take (rough estimate, could be a coincidence). This makes me think that, after dbquit matlab is trying to execute this line again, catches and error or find the breakpoint, and stops in dbmode again.

I hope this makes some sense. Anyone have some experiences like this as well? Not sure if this would be a bug, or weird combination of debug-things i'm using (i.e. dbstop).

PFA bonus image of dbquit not doing anything

Answer 1

[Prabhan Purwar]

Hi,

Could you please provide us the code along with the reproduction steps you have tried in a sequential manner so that we can replicate the issue.

Thanks

Answer 2

[Walter Roberson]

dbquit('all') ends debugging for all files at once.

(Requires a somewhat new MATLAB release.)

However... in practice:

• if you managed to put a breakpoint in a timer interrupt and the timer busyaction was not set to cancel, then the timers are still set to be debugged
• if you have dbstop if naninf in effect and you have background plotting going on, such as fplot(), you are probably going to have a rough time. It turns out that some of the graphics routines are careless about using inf sometimes, such as some that compare values to inf instead of using isfinite(), and some that only need the inf on specific paths but set inf on the common path and then overwrite it on the more specific paths
• if you have dbstop if caught error in effect and you made any of a number of kinds of plot interactions, you are in for "fun". It turns out that parts of the interactions routinely go through paths that are expected to usually trigger errors (unless certain undocumented internal conditions have been set up, hooks to permit substituting alternative routines in places for development purposes, for example.) And it turns out that the relevant routines can get triggered over and over again while you are working in the debugger, because they are triggering on things like you not being in the expected window, which you are not because you are talking to the debugger...

If dbquit all does not work, then clear dbstop if error, dbstop if caught error, dbstop if warning, and dbstop if naninf . These will not always be enough, but they help .

[Reinder Dorman]

I think your third point might be relevant in my case, because this is in a bunch of plotting scripts. I'm also not sure that this is a bug but just a consequence of my workflow at the moment. That's why I think dbquit('all') is a good thing to try when I encounter this again!

(I'll accept this answer when i've got a chance to test this again)