Re: Octave 4.2.1 ambiguity with `clean_up_and_exit()`?

[John W. Eaton]

On 01/11/2018 07:05 AM, siko1056 wrote:
> jwe,
>
> While looking for a solution for bug #52650 [1] I noticed, that the function
> `clean_up_and_exit()` in the standalone demo function [2] is mapped to
> `liboctave/cruft/misc/quit.cc` [3].  I stepped with a debugger into it and
> especially the output is suspicious:
>
>      GCD of [10, 15] is 5
>      terminate called after throwing an instance of 'octave::exit_exception'
>      Aborted (core dumped)
>
> The implementation [3] looks like an emergency break with the `throw`
> statement,
> rather than a gentle exit function.  On the other hand, there is an
> implementation `octave::interpreter::clean_up_and_exit() in
> `libinterp/corefcn/interpreter.cc` [4] that seems to be unused in the
> presence
> of [3], even within `interpreter.cc`.
>
> This last aspect seems very critical to me.  So did I miss something or is
> there an ambiguity on the stable branch?  The good news is, the default
> branch
> seems not effected, you made a great effort in the refactoring there.  The
> bad news is, that the segmentation fault does not vanish by a simple
> `return 0;`.
>
> A similar problem I recently noticed on the mailing-list [5].  Thus what is
> the suggested method to stop the Octave interpreter in 4.2.*?  Otherwise,
> our
> users will have to wait until 4.4.* to get the situation fixed for
> standalone
> builds.

The attached version of embedded.cc should work with 4.2.

It will not work with 4.3.0+ because there is no longer an 
embedded_application object.

As you know, for the current dev sources that will become 4.4, the 
recommended way to create an embedded application object has changed 
(see the new examples/code/embedded.cc file in the current sources).  I 
think it is significantly better now.

I don't know what the best thing is to do to provide some kind of 
transition path.  Maybe we could restore the embedded_application object 
(and simultaneously mark it as deprecated).  But exceptions will still 
be an issue and existing code will probably still have to change, 
otherwise it will likely fail if any execution_exception is thrown by 
the embedded interpreter.

As a further transition path, we might be able to make octave_main and 
clean_up_and_exit work again, but I'm not sure.  As it is now 
octave_main does not work properly for embedded interpreters because it 
creates a temporary embedded_application object that is deleted when 
octave_main returns.  That could be changed to a global or static object 
so that it would still exist after octave_main returns, but there are 
still issues with catching the quit exception.

As I recall, the quit exception is thrown instead of just exiting so 
that Octave can exit cleanly from the top level.  What happens with the 
current stable sources if clean_up_and_exit just calls exit?  Does it 
really clean up?  With the current dev sources, it might work OK because 
more interpreter resources are cleaned up by class destructors.

When I revised this for the current dev sources, I could not see a way 
to preserve the old interface and keep existing code working.  Sorry.

Do you have any ideas about how to fix it while maintaining binary 
compatibility with previous 4.2.x releases?  I couldn't see a way, but 
that doesn't mean there isn't something that could be done.

jwe

embedded.cc
Description: Text Data