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

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

[Octave-bug-tracker] [bug #49515] Octave aborts on exit under some condi


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #49515] Octave aborts on exit under some conditions with --eval CODE
Date: Thu, 3 Nov 2016 01:04:10 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

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

OK, I follow now: this "--eval" mode doesn't even set up that octave_link to
the GUI, so the handshaking sleep/awake doesn't take place at exit.  (Well,
not 100% sure of that, more later.)

So we end up at 692 if "exit(0)" is not called:


        if (! options.persist ())
          {
            m_quitting_gracefully = true;

            clean_up_and_exit (parse_status);
          }


of which we aren't supposed to return from.

This following (from what I'm recalling now):


    if (octave_link::exit (status))
      {
        if (safe_to_return)
          return;
        else
          {
            // What should we do here?  We might be called from some
            // location other than the end of octave_execute_interpreter,
            // so it might not be safe to return.

            // We have nothing else to do at this point, and the
            // octave_link::exit function is supposed to take care of
            // exiting for us.  Assume that job won't take more than a
            // day...

            octave_sleep (86400); // FIXME: really needed?
          }
      }
    else
      {
        if (octave_exit)
          (*octave_exit) (status);
      }


was done so that the GUI could launch Octave core.  But if it is true that the
octave_link isn't fully set up, then octave_link::exit, i.e.,

bool
octave_qt_link::do_exit (int status)
{
  emit exit_app_signal (status);

  // Could wait for a while and then timeout, but for now just
  // assume the GUI application exit will be without problems.
  return true;
}

is emitting a signal to nowhere.  If I recall correctly, the issue was that if
Octave exits directly (rather than having the GUI shut down its thread) then
the main GUI thread displays an error.

Here's the odd thing.  octave_sleep() has a octave_quit() at the end of it.


void
octave_sleep (double seconds)
{
  if (seconds <= 0)
    return;

  double fraction = std::modf (seconds, &seconds);
  fraction = std::floor (fraction * 1000000000); // nanoseconds

  time_t sec = ((seconds > std::numeric_limits<time_t>::max ())
                ? std::numeric_limits<time_t>::max ()
                : static_cast<time_t> (seconds));

  struct timespec delay = { sec, static_cast<long> (fraction) };
  struct timespec remaining;
  octave_nanosleep_wrapper (&delay, &remaining);

  octave_quit ();
}


Could it be that clean_up_and_exit() isn't returning but going to this
octave_quit(), because the timer is timing out somehow?  Or have you confirmed
the return from clean_up_and_exit() in the debugger?

Seems there should be a better way.  The slots for a QThread are as follows:

void    quit()
void    start(Priority priority = InheritPriority)
void    terminate()

The core can emit signals.  I wonder if it is possible to emit a signal from
within the QThread that is intended to terminate.

But still, I'm a bit confused about whether the octave_link is actually
working in the eval scenario.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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