Thank you for testing.

Closing as fixed.

comment #11:

> @rlaboiss: Octave 9.2.0 (which should be including a fix for this issue) has been released approx. a week ago.
> Do you still need to manually append `-fexceptions` to the `CFLAGS` when building the stk package?
> Does exception propagation work correctly (without manually adding that flag) on armel, armhf, and mips64el with Octave 9.2.0?

As soon as the Debian package for Octave 9.2.0 will be released, I will check the points above.

I pushed the patch to the stable branch:
https://hg.savannah.gnu.org/hgweb/octave/rev/60522eca0756

Marking as ready for test.

Perfect. It looks like the patch would fix both issues.

@jwe: Ok to push to the stable branch?

Thank you for testing.

Does Octave still terminate like before on `echo buggy | octave-cli`? Is that issue also resolved by adding -fexceptions to the CFLAGS?

Anyway, attached is a patch that adds -fexceptions to the XTRA_CFLAGS and FFLAGS so that this flag is added when mkoctfile builds C or Fortran sources.
The flag is also used when building any C or Fortran sources of Octave itself.

I tested with the default branch of Octave (where I couldn't see a negative impact). But it would probably make sense to apply that change on the stable branch.
Would that be ok?


(file #56095)

Thanks for the reminder. I forgot about that.

Afaict, we never acted on that discussion. At least, I can't find `-fexceptions` anywhere in the source tree.

Maybe, that would actually help for the problem here.

@rlaboiss: Does adding `-fexceptions` to the CFLAGS when building that .mex file make a difference for you?
E.g., like this:

CFLAGS="$(mkoctfile -p CFLAGS) -fexceptions" mkoctfile --mex --output __buggy.mex buggy.c

Does that still lead to the uncaught exception when you run the following?

echo buggy | octave-cli

Forgot to attach the patch. Here it is.

(file #56075)

For the context of this issue, see the Debian bug #1069477. This bug was filed against the octave-stk package of Debian and is related to a failure in a unit test, during package build.

The build logs indicate failures for the architectures armel, armhf, and mips64el:

>>>>> /<<PKGBUILDDIR>>/inst/sampling/stk_sampling_vdc_rr2.m
***** error __stk_sampling_vdc_rr2__()           % two inputs required
terminate called after throwing an instance of 'octave::execution_exception'
  what():  __stk_sampling_vdc_rr2__: Two inputs required.
fatal: caught signal Aborted -- stopping myself...
Aborted

I investigated this issue and concluded that it is not in the stk package per se, but actually something related to the building of the MEX files.

In order to illustrate the problem, I prepared a tarball, attached to this bug report, containing three files: buggy.m, buggy.c, and Makefile.

The buggy.c file contains the following:

    #include “mex.h

    void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
    {
       mexErrMsgIdAndTxt(“dummy”, “Failed”);
       mexErrMsgIdAndTxt(“dummy”, “End of mex function\n”);
    }

It must be compiled to obtain a __buggy.mex file, like this:

    mkoctfile --mex --output __buggy.mex buggy.c

The buggy.m file contains the following:

    function buggy
        __buggy();
    endfunction

    %!error buggy()

When the buggy function is called, it should produce an error, on all architecture, like this:

    $ echo buggy | octave-cli
    terminate called after throwing an instance of 'octave::execution_exception'
      what():  __buggy: Failed
    fatal: caught signal Aborted -- stopping myself...
    Aborted

When the buggy.m unit test is run, it should yield:

    $ echo test buggy | octave-cli
    PASSES 1 out of 1 test

At least, that's what I'm seeing on my amd64 system. However, when I run the last command on an armhf system, I get this:

    echo test buggy | octave-cli
    terminate called after throwing an instance of 'octave::execution_exception'
      what():  __buggy: Failed
    fatal: caught signal Aborted -- stopping myself...
    Aborted

As you can see, the behavior is not the same depending on the system architecture.

P.S.: Note that when the buggy.c file contains a single call to mexErrMsgIdAndTxt, everything goes fine on all architectures.