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

[Mike Miller]

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

I have now reduced the test case to as simple as


$ ./run-octave --eval "addpath ~/src/octave/octsympy/inst; sym(1); exit(0);"
(gdb) r
...
pure virtual method called
terminate called without an active exception

Thread 10 "QThread" received signal SIGABRT, Aborted.
__GI_raise (address@hidden) at ../sysdeps/unix/sysv/linux/raise.c:58


I thought I had tried this simple test before and it didn't trigger the error,
but now it does.

If I set a breakpoint on octave::interpreter::clean_up_and_exit, it appears to
be called twice. The first time it is called when the eval block calls exit().
This sends the signal over the octave_qt_link to cause the Qt window class and
main application to delete and exit itself.

However, at this point the octave::interpreter::execute function is still
running on the main_thread QThread loop. In fact, by the time the
octave::interpreter::execute_eval_option_code function returns up one stack
frame to octave::interpreter::execute, the main function has already exited
and the main_window, application, interpreter, and octave_qt_link objects have
already deleted themselves.

The next step in the execute function calls the clean_up_and_exit method a
second time, and this is where the abort() occurs.

If I take out the `exit(0)` from the --eval code string, then
clean_up_and_exit is only called after execute_eval_option_code returns, but
again by the time the next routines are in play, the Qt main application and
main function have already exited. The segfault in this case occurs when the
interpreter tries to see if have_script_file() is true, and make copies of the
argv array. Since the application object has been destroyed, it incorrectly
enters this code block and crashes on trying to store argv into Octave string
objects.

Maybe the key to this bug is the popen2 that is left open pointing at the
Python interpreter process. It's possible that the delay from closing the
Python process is slowing down the clean_up_and_exit part of the interpreter
to the point that this bug is exposed.

    _______________________________________________________

Reply to this item at:

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

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