Debug stack on error

Dear all,

since I use the newer version of Matlab, I habe a problem with the debug mode. Whenever I use dbstop if error, the debugger stops miles deep in some Matlab functions and not at the position of the error. Even if I try to step through the call stack, I only step though a lot of Matlab functionality until I end up outside of debug mode.

Why is this happening? I really loved to use dbstop if error and now it is useless to me.

Best regards

[Adam Danz]

At the very least we need the full error message. It may also be helpful to run the following command at the point where the break occurs while still in debug mode and share the results.

dbstack

If the problem is reproducible, I'd like to tinker with it on my end, but I would need to lines of code that cause the problem.

[Bjorn Gustavsson]

That occurs to me too - sometimes. For me it was a case of loosing my patience and repeating dbup too many times in quick succession without looking where I should stop.

[Alexandra]

I tried some different combinations, and it seems the problem only occurs in appdesigner applications. The output of dbstack is

> In appdesigner.internal.service/AppManagementService/tryCallback (line 391)
  In matlab.apps.AppBase>@(source,event)tryCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 35)
  In matlab.ui.control.internal.controller/ComponentController/executeUserCallback (line 382)
  In matlab.ui.control.internal.controller/ComponentController/handleUserInteraction (line 332)
  In matlab.ui.control.internal.controller/PushButtonController/handleEvent (line 86)
  In appdesservices.internal.interfaces.controller/AbstractController/handleProxyViewEvent (line 280)
  In appdesservices.internal.interfaces.controller.AbstractController>@(src,event)handleProxyViewEvent(obj,src,event) (line 208)
  In appdesservices.internal.interfaces.view/AbstractProxyView/notify (line 117)
  In appdesservices.internal.peermodel/PeerNodeProxyView/handlePeerEventFromClient (line 252)
  In appdesservices.internal.peermodel.PeerNodeProxyView>@(varargin)obj.handlePeerEventFromClient(varargin{:}) (line 84)
  In hgfeval (line 62)
  In javaaddlistener>cbBridge (line 52)
  In javaaddlistener>@(o,e)cbBridge(o,e,response) (line 47)

In this case, the code causing the error is a simple assert statement, but it happens to all errors in the app

[Adam Danz]

Too bad we don't have an example of a full error message. That would have helped us out a bit.

Depending on what's causing the error (which may be indicated in the full error message), this behavior may be expected with app designer. Or, it may indicate that the app is corrupted.

[Alexandra]

What do you mean by full error message? The error message is just

Error using SicfView/RunSicf (line 457)
     Assertion failed.

as I said. And the problem is that I do not end up in RunSicf line 457 as I expect, but in AppManagementService, line 391.

I could try to make a simplified version of the app for you to run.

[Adam Danz]

I wonder what part of the assertion at line 457 is going bad. Perhaps you could place a break point on that line and then cause the error so that it stops at that line before continuing. Then look at the inputs and share that line of code and its inputs. Is SicfView/RunSicf something your wrote in your app?

Having a working example may be helpful - I could at least report whether it's happening on my end or not.

[Alexandra]

There you go. If you click the import button, an error is generated (by assertion or directly throwing an error) and I end up in AppManagementService

[Walter Roberson]

dbstop if caught error

[Adam Danz]

Thanks for the demo file.

The behavior you describe is expected. From the documentation,

"dbstop if error pauses execution at the first run-time error that occurs outside a try/catch block.". In this case, execution is stopped when the caught error is thrown within AppManagementService.m.

As Walter Roberson pointed out, for "dbstop if caught error", execution pauses within the try-portion of a try/catch block and the callback function is executed within the try portion.

[Alexandra]

Thank you for the answer. I was not aware of that. Did that behaviour change somewhere in the last few Matlab versions? I never encountered it that way before.

With "dbstop if caught error", I get several stops due to try-catch-blocks in Propertyhandling, before I come to the section above, but I guess it is better than before. Thank you for that tip.

[Bjorn Gustavsson]

If that becomes too cumbersome you could consider temporarily removing the "protecting try-catch" around the code you want to investigate - it might make the debugging-process slightly less anoying.

[Adam Danz]

@Alexandra once you know where the error is, you can always put a break point on that line and then run the code without any dbstop's. That how I troubleshoot most of the time.

@Bjorn Gustavsson, by "removing the protecting try-catch", do you mean commenting-out the "try" and the catch-block? I don't have Alexandra's app open now but I recall that the callback function was executed internally within a try/catch, within Matlab app functions. I believe this line of the error stack points to it,

In matlab.apps.AppBase>@(source,event)tryCallback(appdesigner.internal.service.AppManagementService.instance(),app,callback,requiresEventData,event) (line 35)

Otherwise, commenting out the try/catch would be a good idea.

[Bjorn Gustavsson]

@Adam, Yes, exactly that. Explicitly setting the break-point is typically better, but if the error occurs seldom commenting out the try and catch to "expose" the function-call and get the debug-stop only when the error happens, can be useful too. (Since I typically debug in anger, peculiar actions are taken)

[Adam Danz]

@Bjorn, 😃 I know exactly what you're talking about. The problem with commenting-out the try/catch in this case is that it's part of a Matlab function so alterations to that file are not an option. The OP could write her own try/catch around the problematic section of code to troubleshoot that way, though.

[Alexandra]

Usually, I set a breakpoint on the line (as suggested), but if the error doesn't occur very often, I used to do "dbstop if error". But using a try and catch block around the section works well, too. Thank you for all the suggestions :-)