octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #55226] building doc figures in .png format oc


From: Mike Miller
Subject: [Octave-bug-tracker] [bug #55226] building doc figures in .png format occasionally fails with error in getframe: unable to retrieve figure pixels
Date: Fri, 14 Dec 2018 16:23:47 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

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

                 Summary: building doc figures in .png format occasionally
fails with error in getframe: unable to retrieve figure pixels
                 Project: GNU Octave
            Submitted by: mtmiller
            Submitted on: Fri 14 Dec 2018 01:23:45 PM PST
                Category: Plotting with OpenGL
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Build Failure
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

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.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]