Closing a modal dialog may hang Matlab
The last time this happened was only two days ago, and by pure coincidence a reader’s comment yesterday happened on the same page where I explained the problem and solution. So I am taking this opportunity to explain the problem and the workaround, before my senility takes over and I forget again… 
The symptom – Matlab hangs
The symptom is easily detectable: you’re happily working on your favorite Matlab GUI application, when suddenly some modal dialog window appears – perhaps a msgbox, a questdlg or an inputdlg. After clicking the <OK> button, Matlab seems to freeze, and any attempt to close the window or to stop the GUI fails. Forget about Ctrl-C – it simply hangs.
The only workaround is to open the operating system’s task manager and kill the Matlab process.
There are several odd things here: Firstly, the task manager shows that the Matlab process is not consuming any CPU. Secondly, the hang does not appear consistently – sometimes it does, other times not, making debugging extremely difficult. Moreover, when we debug the code, stepping through the source-code lines one at a time, everything seems to behave perfectly normal; it is only when running the program in continuous mode that the hang appears.
The solution – adding drawnow
The underlying reason for the hang appears to be that when we close the modal dialog window, it is sometimes not yet fully destroyed when we proceed with our program. It is my belief that this creates race-conditions which in some cases cause a deadlock between Matlab’s Main Thread and Java’s Event Dispatch Thread (EDT). Matlab-EDT synchronization problems are often time-dependent, which explains why the hang sometimes occurs and sometimes not.
While debugging EDT synchronization problems is notoriously difficult, the solution is often extremely simple — Just add a combination of drawnow and a short pause:
uiwait(msgbox(...)); drawnow; pause(0.05); % this innocent line prevents the Matlab hang answer = questdlg(...); drawnow; pause(0.05); % this innocent line prevents the Matlab hangswitch answer ...
Adding drawnow and pause forces Matlab to flush EDT’s event queue, thereby ensuring synchronization before proceeding with the Matlab code. This is actually quite important when integrating Java GUI components in Matlab figures (especially before R2008b’s javaObjectEDT became available).
In the particular case of the Matlab dialog hang, drawnow is probably sufficient and pause is unnecessary. As noted by Bill York (MathWorks’ dev team leader who is responsible for such stuff) here, drawnow is similar but not exactly the same as pause. I often use both of them, since I discovered via trial-and-error that in the general case of EDT-related timing issues, different situations respond better to either of them, and I never remember which one to use to ensure proper rendering. So the drawnow/pause line appears very often in my code, quite possibly even in places where they are not strictly needed.
The actual needed value of the pause may vary, depending on GUI complexity and CPU power/load, but 0.05 seems to be large enough for most cases, while being small enough to be virtually unnoticeable by the user. In rare cases I needed to go as high as 0.1, but then again in some cases it is not needed at all.
Related posts:
- Solving a MATLAB bug by subclassing Matlab's Image Processing Toolbox's impoint function contains an annoying bug that can be fixed using some undocumented properties....
- Fixing a Java focus problem Java components added to Matlab GUIs do not participate in the standard focus cycle - this article explains how to fix this problem....
- A couple of internal Matlab bugs and workarounds A couple of undocumented Matlab bugs have simple workarounds. ...
- Spicing up Matlab uicontrol tooltips Matlab uicontrol tooltips can be spiced-up using HTML and CSS, including fonts, colors, tables and images...
- Matlab and the Event Dispatch Thread (EDT) The Java Swing Event Dispatch Thread (EDT) is very important for Matlab GUI timings. This article explains the potential pitfalls and their avoidance using undocumented Matlab functionality....
- Images in Matlab uicontrols & labels Images can be added to Matlab controls and labels in a variety of manners, documented and undocumented. ...
I am glad to see that I am not the only one to have this issue. I get this issue on Windows Xp Win32 since R2011b . I exactly use the same workaround by adding a pause(0.1) after each dialog box , otherwise MATLAB freezes or requires some time to be able to close the dialog box. It often occurs when I have a lot of code just after the dialog box . It is just like if MATLAB was already interpreting the rest of the code before the user clicks on the dialog box…. As I was never able to reproduce easily this issue with a simple code , I never submitted technical support request.
I’ve gotten a very similar problem on numerous occasions, though I’ve never been able to find mention of it online. When I use alt+tab (Windows 7, R2009a) to switch between the command window and an auxiliary Matlab screen (help, find files, …), it occasionally hangs. Button mashing sometimes fixed it, though I could never find out what the exact trigger to resume was. I later realized killing the specific process through task manager was a better solution.
Thanks for the great blog, Yair. I’m surprised you don’t have a cushy job at MathWorks by now, unless, of course, you don’t want one!
Yes, this can be very irritating. Wasted over an hour on this the other day before sticking in a drawnow. What was “interesting” was that the very same code that would hang in R2012b ran flawlessly in R2011a. We will just have to program defensively and put them in all these situations I guess..
I was just trying to figure out this same issue myself – perfect timing on your post! Thank you.
Yes. I had similar issues too!
I blogged about it.
I would tend to think this is a serious Matlab bug as the behavior is not expected and can lead to very long and annoying debugging.
I have the feeling Matlab is most of the time unstable due to its interaction with Java. What do you think?
In general, every time I get a Java error like this in Matlab, I feel a little lost. These are the most difficult to debug. So this post was very helpful.
@Jerome – I wouldn’t go as far as saying that the Matlab-Java interface makes Matlab unstable. I believe that if we stick to some well-defined rules (that I have outlined in section 1.5 of my book), then we should be ok and our application would be quite stable.
I would of course hope that making a stable high-quality GUI would involve less hand-crafting by Matlab users than currently required, but this is still a long way from saying that it is unstable or unuseful.
I do agree that debugging such issues can often be frustratingly difficult. I can only console you that it gets easier with experience, as the problems tend to be similar to each other, and the solutions similar as well.
@Yair: I would have to disagree with you. You have to sprinkle your code with undocumented workarounds just to prevent it from hard freezing under ordinary usage, with no debugging information provided to help you figure out what went wrong. If that is not unstable, then what would be?
Hi Yair,
I’m having a similar (I think…) problem, with pop-ups that are created from uimenus.
For example I’m having a rather busy gui out of which one uimenu calls a another function, that creates a figure waiting for user input.
I’m regurlary encountering the issue, that those kind of pop-up windows (also e.g. the “questdlg”-figures) are not drawn properly.
For instance their background is transparent, some ui-elements don’t appear at all, etc.
I’ve already distributed pause & drawnow-calls, but these didn’t solve the problem.
I’d be glad about any idea on how to solve this.
Hey,
I encountered a similar-ish behaviour with a slider that positions a plot object within my gui. Everything worked smooth when positioning by either clicking in the slider’s trough or via numerical values of an additional text box (that always shows the current position values – I guess you get the idea).
BUT upon moving my plot object via clicking the slider’s arrows, the slider itself kept moving until reaching its min or max value, freezing Matlab on its way.
I first tried “pause(0.05)” as in your example, but I only got my slider’s behaviour right once I changed to “pause(0.1)”.
Long story short: thanks for your post, it helped a great deal. (Though I’ve got no idea why the length of the pause should be substantial to your workaround.)