Thank you, this looks fixed for me now.

I attached an updated version of the patch. I added a FIXME note about not being able to restore the previous state of the mutex, but I think it is an overall improvement. So I'll push it if no one opposes.



(file #45707)

Thank you, I'm attaching an edited version of the patch for small style fixes:

• trailing whitespace
• it is safe to delete null pointers

The patch works perfectly for me. I've tested both calling "test getframe" in a shell loop as well as generating the user manual png images in a loop, and all works for me reliably now.

I will next test that this also fixes bug #55225.

(file #45681)

>> Anyway, the cset.

should read "Anyway, can you test the cset."

I guess it would be nice to have octave-client (similarly to emacs-client). Probably not for 5.0 though....

Dmitri.
--

On Ubuntu 18.10, nvidia drivers, first code shows no failure (2 runs), while second one fails sporadically (~10 times, 2 runs).

Building default almost always shows the getframe failure.

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.

On my system, building the figures for the user manual in the .png format occasionally fails with the error

error: getframe: unable to retrieve figure pixels

At this point, Octave exits with an error and the build fails.

This is very similar to bug #55225, but not exactly the same. In both reports, I can reproduce the error by repeatedly running the same command in serial and eventually seeing a failure. However, when printing to the .eps and .pdf formats, there is no error message and Octave appears to exit successfully. In the .png format, there is a clear error message and Octave exits with an error.

After tracking down the "FIXME" workaround where this error message is reported (see bug #53328), I was able to add a fourth iteration to the code with a much longer delay:

--- a/libgui/graphics/ObjectProxy.cc
+++ b/libgui/graphics/ObjectProxy.cc
@@ -24,6 +24,8 @@ along with Octave; see the file COPYING.
 #  include "config.h"
 #endif

+#include <iostream>
+
 #include <QCoreApplication>
 #include <QString>
 #include <QThread>
@@ -152,7 +154,13 @@ namespace QtHandles
             octave::sleep (0.2);
             if (! QMetaObject::invokeMethod (m_object, "slotGetPixels", t,
                                              Q_RETURN_ARG (uint8NDArray, retval)))
-              error ("getframe: unable to retrieve figure pixels");
+              {
+                std::cerr << "octave::ObjectProxy::get_pixels: slotGetPixels failed three times, sleeping longer" << std::endl;
+                octave::sleep (3.0);
+                if (! QMetaObject::invokeMethod (m_object, "slotGetPixels", t,
+                                                 Q_RETURN_ARG (uint8NDArray, retval)))
+                  error ("getframe: unable to retrieve figure pixels");
+              }
           }
       }

With this change, the "failed three times" message is printed occasionally, where it would have failed, but now with the additional 3 second delay it never fails for me. An initial attempt with a 0.5 second delay was not enough.

This hack does not affect bug #55225, probably because the .eps and .pdf formats are not using the same 'getframe' code path.