dbstop if error stops in "drawnow"

9 views (last 30 days)
N/A on 12 Oct 2017
Commented: Jan on 13 Oct 2017
Dear Community,
I'm facing a rather odd problem and want to know if someone experienced a similar problem, or even knows a solution.
I usually have
dbstop if error
enabled. In a script that prints png-files with bargraphs the debugger stops in
36 drawnow; % give changes a chance to be processed
The Function Call Stack is: Base * myscript * print alternatePrintPath
Quit Debugging or Continue often results in another stop after 5-10 seconds of processing.
My script does nothing fancy, the only "unusual" thing in my mind might be that the struct from which the pngs are plotted is over 1 GB in size. The break by the debugger is not labeled as an error just as shown above as "36 drawnow ..." in the internal print.m
Without "dbstop if error" the script just runs fine.
  1 Comment
N/A on 13 Oct 2017
Edited: N/A on 13 Oct 2017
Adding a
pause(0.02); % Avoid debugger stops in Matlab 2017a.
% Walter has suggested it in the forum.
% Does not help after PRINT, but before
% ?*? Review 2018
before the print prevents the debugger from stopping. Walter suggested it in a comment below.
This circumvents the problem, be careful with such magic :)

Sign in to comment.

Accepted Answer

Jan on 12 Oct 2017
Edited: Jan on 12 Oct 2017
drawnow stops with an error, if a graphic object has been created, which cannot be displayed correctly, e.g. a listbox with the 'Value' set higher than the number of elements. Or a slider with the value outside the defined range. Or A listbox with a single selection activated, but the value is empty.
Then updating the graphics fail "inside" drawnow. But you should get a corresponding error message directly. But you do not mention any message, but only the calling stack.
What does "results in another stop after 5-10 seconds" exactly mean? Where does it stop?
What does "The break by the debugger is not labeled as an error" mean and what is the "internal print.m"?
You wrote that you "usually" run your code with the enabled dbstop. Are you aware that Matlab's JIT accelerator is disabled then? Some loops might be up to 100 times faster without enabled debugger.
Can you post a piece of code, which reproduces the error? Currently the problem looks really strange and magic, but this means usually, that something trivial happens that the programmer is not aware of. Without seeing the code, it is hard to guess such details.
Jan on 13 Oct 2017
The pause(0.02) seems to trigger the processing of the Java event queue. The drawings of objects is not performed, when they are created, but only when a screen update is triggered. This reduces the number of expensive updates e.g. for:
H = plot(1:10, rand(1,10));
set(H, 'YData', -rand(1-10));
If the screen is updated directly after the first command, the double work is needed. Therefore Matlab waits until a pause or drawnow command occurs, or the CommandWindow is activated.
Many (or all?) graphic objects are implemented in Java, which has an own event queue. Sometimes the processing of this queue is not finished, when Matlab expects it to be, e.g. if you use getframe on a figure, which contains uicontrols. Sometimes the uicontrols like buttons are not drawn yet and getframe records the pixels from the underlying window or desktop background instead. Then a pause(0.02) helps also.

Sign in to comment.

More Answers (0)


Find more on Migrate GUIDE Apps in Help Center and File Exchange

Community Treasure Hunt

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

Start Hunting!

Translated by