[Octave-bug-tracker] [bug #49515] Octave aborts on exit under some conditions with --eval CODE

[Mike Miller]

Follow-up Comment #7, bug #49515 (project octave):

Absolutely, I would not call this a solution. All I've done is confirm that
the persistent open pipe to the python executable that octsympy opens helps to
provoke the condition that leads to this error.

I guess the expectation is that the clean_up_and_exit function is supposed to
never return if the safe_to_return flag is false (which it is in all of my
testing). However, the method does seem to be returning from its
supposed-infinite sleep and causing the crash I am running into.

I made the following quick-n-dirty hack


diff --git a/libinterp/corefcn/interpreter.cc
b/libinterp/corefcn/interpreter.cc
--- a/libinterp/corefcn/interpreter.cc
+++ b/libinterp/corefcn/interpreter.cc
@@ -1078,7 +1078,11 @@ namespace octave
             // exiting for us.  Assume that job won't take more than a
             // day...
 
-            octave_sleep (86400); // FIXME: really needed?
+            do
+              {
+                octave_sleep (86400); // FIXME: really needed?
+              }
+            while (true);
           }
       }
     else


and now I no longer get any abort or segmentation fault with any of the cases
that did reliably crash on me without this change.

The answer to the FIXME seems obvious, yes, something is needed in this
function to prevent it from returning when it has told the GUI thread to exit
the application. What's in there now doesn't seem to be sufficient.

Cc jwe, you added the code to relay the exit over the octave_qt_link back in
2013 (http://hg.savannah.gnu.org/hgweb/octave/rev/8b783661e03f), any thoughts?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49515>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/