[Octave-bug-tracker] [bug #55226] building doc figures in .png format occasionally fails with error in getframe: unable to retrieve figure pixels

[Mike Miller]

Follow-up Comment #2, bug #55226 (project octave):

I've done some more testing of this bug and how it relates to calling the
'getframe' function directly. This bug now seems very closely related to bug
#53328, because I can also still reproduce the same error message with
test('getframe').

One important observation is that this may have to do with 'getframe' being
called very early in the Octave process lifetime, while either Octave's
graphics subsystem or Qt's internals are still being initialized.

The following loop, for example, gives me zero test failures, everything seems
all good


$ ./run-octave -qfH --eval "for i = 1:1000; test('getframe'); endfor"


But rewriting this as multiple independent invocations of Octave from the
command shell *does* give me test failures, 24 out of 1000 on the last run


$ for i in $(seq 1 1000); do ./run-octave -qfH --eval "test('getframe')";
done


Can someone else test and compare these two different loop syntaxes on their
system to see if they can reproduce my problem?

This is exactly how our build system works to generate the figures for the
user manual, launching a new Octave instance to plot and save the figure as an
image file each time.

If this can be confirmed, it might also be interesting to see if some time
delay after starting Octave prevents this error from happening, and if this
was also the cause of bug #53328, and if anyone has any insights into what
might be causing this or what might not be initialized fully yet.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55226>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/