I stepped through print.m and the line that makes the axes appear is

  set (opts.figure, "position", fpos);

fpos is

    fpos = get (opts.figure, "position");
    ...
    fpos(3:4) = opts.canvas_size;

If the new position is different from the original, the plot updates and the axes appear.  Setting other properties doesn't seem to change anything, though I haven't tried them all.  Maybe it is just a missed drawnow and the other properties aren't affecting the "modified" status of the figure object?  I haven't checked.

Thanks for pushing the patch.

I'm closing this report and opening a new one about the allchild compatibility.

The print trick works for me.  I tried

./run-octave --persist --no-gui --eval "newplot; newplot; drawnow;"

until it failed with a blank figure window.  A "print foo.png" command made the axes appear.  So I guess this is some other kind of race condition involving rendering and drawnow?  But although printing the figure worked to fix the display, I couldn't seem to get that to happen with something that should force a redraw like

set (gca, 'xlim', [-5, 5]);

So maybe it is more complicated that just missing a drawnow request.

For what its worth, the results from the tests from comment #15 and comment #16 in Matlab R2016a:

>> labels = {'xlabel', 'ylabel', 'zlabel', 'title'};
hlabels = cell2mat (get (gca, labels));
Error using cell2mat (line 52)
CELL2MAT does not support cell arrays containing cell arrays or objects.

Fails because graphics handles are objects now.
Slightly modified keeping the spirit of the test:

>> close all
>> labels = {'xlabel', 'ylabel', 'zlabel', 'title'};
>> hlabels = get (gca, labels);
>> hparents = get ([hlabels{:}], 'parent');
>> all ([hparents{:}] == gca)

ans =

     1

>> allchild (gca)

ans =

  0x0 empty GraphicsPlaceholder array.

There may be other places where data should be protected, but I think the blank window is another story.

My guess is that it is something like bug #44472: at some point the concurrency (imposed by mutex) between the GUI and the interpreter makes the GUI thread miss a drawnow_requested.

I tried running the following shell command after applying your change:

while true; do ./run-octave --no-gui --eval "newplot; newplot; drawnow; pause (1);"; done

It never seems to segfault, but it does occasionally fail to display the axes in the plot window.  Maybe there is some other place where we need a lock?

In any case, please push your change as it does seem to be a significant improvement.

Thanks.

Is "reset" ever called when running "sphere (64)"? That is not what I would expect.

I think it is directly operations on txt_renderer objects that should be mutex protected. If I do that in graphics.cc, see attached, I am then unable to trigger the crash.




(file #39645)

Try this also:

allchild (gca)

Does that return a list of 4 handles in Matlab?

Yeah, I think it's a race condition.  The attached change helps, but I can still trigger the problem:



(file #39644)

And now I have a crash (actually plot hangs)...
At first glance -- nothing has changed.

Dmitri.

I still can't reproduce this using

newplot; newplot

but clearly I am in the minority.

If the problem is with allchild, does this quick fix work?

diff -r 35e3d199527c scripts/plot/util/newplot.m
--- a/scripts/plot/util/newplot.m       Tue Jan 31 17:29:32 2017 -0800
+++ b/scripts/plot/util/newplot.m       Wed Feb 01 12:16:16 2017 -0800
@@ -198,7 +198,10 @@ function hax = newplot (hsave = [])
           delete (ca);
           ca = axes ();
         elseif (do_reset)
-          delete (allchild (ca));
+          ht = [get(ca, {"xlabel", "ylabel", "zlabel", "title"}){:}];
+          ac = allchild (ca);
+          hdel = setdiff (ac, ht);
+          delete (hdel);
           reset (ca);
         endif
       endif

The diff is attached as well if you want to download for testing.


(file #39642)

This problem definitely shows up for me at

changeset:   23013:5dca1727ce94
user:        Pantxo Diribarne <pantxo.diribarne@gmail.com>
date:        Thu Jan 05 09:55:28 2017 +0100
summary:     cla.m, newplot.m: make use of reset function to cleanup listeners (bug #49980).

I can trigger the crash with something as simple as

newplot; newplot

I.e., two successive calls to newplot without an intervening call to drawnow.

This happens for sphere because it calls surf and both call newplot.

The crash happens on the second call to newplot, around line 200.  At that point I think the axes object is newly created and has four children (text objects) and deleting them and calling reset isn't the right thing.  Actually, just the call to reset seems to be causing the trouble because commenting that out appears to allow the code to work.  I'm not sure whether this sequence of commands makes sense, but even if they are nonsensical, they shouldn't crash Octave.

I was testing in a virtual machine with Ubuntu 16.10 (Unity desktop) on a host with Intel i5 CPU with integrated graphics.

It also hangs or crashes on Windows 10 which is the host OS. Changing affected OS to "Any".

I can confirm that the first affected revision is indeed http://hg.savannah.gnu.org/hgweb/octave/rev/5dca1727ce94

I am getting the same behaviour as described by Pantxo: sometimes it crashes immediately, sometimes I get messages about missing glyphs or Octave might hang. For spheres with less faces it sometimes works without an issue.

Is it possible that FreeType needs to initialize the fonts (or something) that was implicitly done by _go_axes_init_ before that change? I am wondering why it wouldn't find the glyphs.

On i7-2600 computer I get sporadic crash or near endless list of warnings about unknown glyph (30), but then it just works
many times in a row.
HG ID for this build is "35e3d199527c"

I wonder if this is desktop dependent -- I have gnome and may
be Qt needs to initialize something (fonts handling), which is
active on Qt-based desktops.

Dmitri.

The segfault happens while trying to render the string "0.6" using ft_text_renderer::text_to_pixels which leads me to two remarks:

• we are trying to render the default axes (the expected 3D final axes does not have "0.6" ticklabel) which I wouldn't expect unless a spurious drawnow is called in the middle of the process
• the ft_renderer tries to find the character '%x'. What does this mean??? I am clueless

I can reliably crash octave with the current tip (17a3567a7b01) if I try to plot a sphere with qt toolkit (fltk is ok). The following is enough

# axes ()
sphere (64)

It has to be run as the first plotting command. Adding "axes ()" prior to plotting the sphere is enough to avoid the crash, which makes me think it has to do with this cset:
http://hg.savannah.gnu.org/hgweb/octave/rev/5dca1727ce94

I'll try to run this in gdb ASAP