Short Pause doesn't come back

Using App Designer I was running my program with no breakpoints set.

Suddenly it stopped running in a place it shouldn't so I broke out to see what's going on and found this:

My understanding is that the open arrow signifies a place where the code has called a routine and not come back yet.

So what's wrong with this pause this time, after it ran fine 9 times in the last 10 seconds or so?

[Swastik Sarkar]

Hi @Gavin,

Could the app implementation be attached here to enable more effective assistance from the community?

[Gavin]

It's over 3000 lines of code (and comments) and requires an Arduino Pico to run it.

If you want a look have at it. But the question is why would pause(0.1) not return immediately once in a blue moon. I've not seen this happen more than a few times with extensive testing.

[colordepth]

I suspect that while your app is running, MATLAB might be handing control over to another part of your code that never returns, possibly due to some asynchronous logic or hardware communication. To illustrate such a deferment, I created a simple app (see attachment) with two buttons:

The callback functions for these buttons are set to pause for 2 seconds and 5 seconds, respectively:

Let's examine what happens when I press them quickly one after the other:

Notice how the "pause(2)" function ends up running for 5 seconds; this indicates that the execution of the first button's callback was deferred until after the second button's click event finished. The "Interruptible" property can control this behaviour in my provided example app: https://www.mathworks.com/help/matlab/creating_guis/interrupt-callback-execution.html

I don't think "pause" is necessarily the issue here; it might just be the slowest instruction in your loop, making it more probable to observe it being affected by such deferment.

Is there a similar situation in your application where a separate logic might start executing during the loop in your code?

[Rik]

Using drawnow to force a refresh might solve this, but I can't currently test this assertion.

[Gavin]

After completely crashing a few times I restarted ML and now it's working fine. I didn't change my code but I noticed after recovery that some of my callbacks had been disconnected from their components. For whatever reason it's all working now.

[Gavin]

I'm still wondering what the hollow arrow means. Something higher on the stack of processes needing attention?

Answer 1

[Dirk Engel]

The white/hollow arrow indicates that the line is currently executing, but that the workspace is currently unloaded. Consider the following case where the debugger stopped at the break point. The workspace of function print() is currently loaded, but the workspaces of functions button_Callback() and createButton(), which are up the call stack, are currently unloaded.

So, you have access to the local variable "text", but not to the variables "obj", "s", "e". If you step up the callstack, e.g. using dbup, the workspace of button_Callback() gets loaded and the worspace of function print() gets unloaded.

Now you have access to the local variables "obj", "s" and "e", but not to "text".

Note that, as a side effect, the pause() function executes pending callbacks. There probably was a callback function executing down the call stack which was stuck for whatever reason. Assumingly, that function was a builtin function, in which case the debugger jumps to the first non-builtin function up the call stack instead. And since the workspace of another function down the call stack was loaded, you got the white arrow. Next time, take a look a the workspace editor. It may provide some clues.