How to do workaround MATLAB crash in set(gcf,'C​urrentAxes​',ax1)?

6 次查看（过去 30 天）
Patrik Ek
Patrik Ek 2014-11-5
回答： Kelly Kearney 2014-12-8
Hi,
I have used matlab for a long time and always liked it. That to say until version 2014b. This version seems to have severe concurrency problems. I got this crash today:
Error using matlab.ui.Figure/set
Axes must be an existing child of figure.
Error in nrOfUEs (line 87)
set(gcf,'CurrentAxes',ax1);
Error in Throughput_stats (line 1071)
nrOfUEs(Stop, NrUE);
Error in femto_all_thrp (line 60)
Throughput_stats(...
87 set(gcf,'CurrentAxes',ax1);
But in debug mode right after this crash manually typing
K>> set(gcf,'CurrentAxes',ax1);
Does not give an error. There are a few possible causes to this problem, depending on what the error message really mean in matlab:
1) The handle is not created
This is however unlikely since the loop
while ~ishandle(ax1)
fprintf('waiting...\n');
end
is not triggered.
2) The handle is modified in row 79 and is thus locked with a mutex lock or other preferred lock
3) The axes are modified, and thus not accessible
There may (mostl likely) also be other possible issues with this. The question is
Are there any workarounds to this problem?
My relevant code row 78-87
78 % Link the x-axes (for zooming purpouse)
79 linkaxes([ax1 ax2], 'x');
81 % Set the original axes to be the current (in case you want to modify it or
82 % anythin)
83 while ~ishandle(ax1)
84 fprintf('waiting...\n');
85 end
87 set(gcf,'CurrentAxes',ax1);

请先登录，再回答此问题。

采纳的回答

Patrik Ek
Patrik Ek 2014-11-5
I just found an answer to the problem, but I still wanted to publish this question to raise the problem. I would not be able to send a bug report to this problem since I would in that case have to submit company secrets. Also this would not come until earliest update 2015b.
The workaround I found was:
while ( ~any( get(gcf,'Children')==ax1 ) )
pause(1);
fprintf('waiting...\n'); % Not necessary, but this helps to see if the code enters the loop
end
This gives the other thread time to finish the GUI.
I would be happy for suggestions about title to reach a larger audiance.
Good Luck All!

更多回答（2 个）

Mike Garrity
Mike Garrity 2014-11-5
From the error message, my guess is that you've got multiple figures, and gcf isn't what you think it is.
Perhaps something more like this would be appropriate:
set(ancestor(ax1,'figure'),'CurrentAxes',ax1)
That's saying that you want ax1 to be the CurrentAxes of its figure, rather than saying that you want ax1 to be the CurrentAxes of whatever figure happens to be gcf at the moment.
  3 个评论
显示 1更早的评论
Mike Garrity
Mike Garrity 2014-11-14
No, that kind of assumption about which figure is gcf has never really been safe. You should always check which figure is current instead of assuming.
Consider the following example:
nfigs = 10;
figs = [];
pos = get(0,'DefaultFigurePosition');
for i=1:nfigs
figs = [figs, figure('Position',pos + i*[10 -10 0 0])];
end
for i=1:100000
f = figs(randi(nfigs,1));
figure(f);
pause(.1);
if gcf ~= f
disp wrong
end
end
While this is running, try clicking on different windows, or if you're on Windows, try using ALT-TAB. You'll see that in any version of MATLAB you'll occasionally see that "wrong" message. That's because the current figure can be set in more than one way. The MATLAB code that is calling figure can't safely make assumptions about what's happening on the other side, and that call to pause lets events in from the other side.
I think that it is true that this might happen more frequently in R2014b. That's because more of the graphics work has been moved off of the compute thread. But the possibility that gcf changed during the pause is not new.
The little code snippet I gave you will always set the CurrentAxes property on the correct figure, regardless of whether that changed during the pause, because the call to ancestor always returns the figure which ax1 belongs to, even if that's not gcf.
Patrik Ek
Patrik Ek 2014-12-8
I am not sure if this s really the cause. What I know this requires some user interaction, what I did was actually that I started the program and not touching anything since I know that activating different figures can cause the current figure to change. The thing that were a bit disturbing was that using code that have been run for many years and that have never crashed so far suddenly crashed. What also was strange was that waiting until the handle existed worked.
To clarify. Without me touching the mouse, the keyboard, while running the given code on a newly restarted computer, got this error. What I had done was creating the figure in question, creating some plots in the figure and then in the end set ax1. It feels strange that the current figure should then not be the one that I required here. It is also strange that without further user interaction suddenly after less than 0.2 seconds (lowest time tested) suddenly getting the right figure as gcf. It feels as if something is fishy here, but I am not sure what.

请先登录，再进行评论。

Kelly Kearney
Kelly Kearney 2014-12-8
I'm not sure if it's entirely related, but I have also found the need to throw a lot of drawnow commands into some of my code in order for it to be compatible with R2014b.
Same basic symptoms... a command that accesses the properties of a graphics object would return an error, but if I placed a breakpoint on that line, the error would not be reproduced. Adding a drawnow just before the command fixed the issue by forcing a mid-calculation render, but it's not an ideal solution (since in my case this results in intermediate-stage rendering, i.e. graphics objects that flash on and off as they're being repositioned, while older versions were able to do this repositioning behind the scenes).
When I submitted a bug report about this, they said this wasn't a bug but just a "timing issue". My takeaway was that at least for now, when programming for 2014b, never assume that a graphics-related line of code will be fully executed before the program moves on to the next graphics-related command, unless you explicitly force it with a drawnow.

类别

在 Help Center 和 File Exchange 中查找有关 Graphics Object Programming 的更多信息

标签

Community Treasure Hunt

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

Start Hunting!

Translated by