bugGNU Octave - Bugs: bug #49296, mex functions built with MSVC...

 
 

bug #49296: mex functions built with MSVC don't work with errors in Octave built with MinGW

Submitter:  Bill Greene <billgreene>
Submitted:  Sat 08 Oct 2016 02:15:36 PM UTC
   
 
Category:  Interpreter Severity:  1 - Wish
Priority:  1 - Later Item Group:  Feature Request
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 13 Oct 2016 10:41:54 PM UTC, comment #6: 

I certainly wouldn't advocate change any across-the-board changes to
how errors are handled in Octave-- now or in the future. But I think of
mex files as basically an "external" C interface to Octave or matlab
(as opposed to oct files) and so it is worthwhile to provide as much
flexibility as possible to the writers of those.

My thought was just to use the setjmp/longjump (or similar) mechanism only
within the mxErr* functions. I don't know much about the internals of
Octave but I assume there is a place in the code where there is some
data structure conversion and then the mex shared library invoked.
Seems like this would be a good place to set up the setjmp/longjmp
mechanism. Then, once the execution point is no longer in the mex
shared library, a C++ exception can be safely thrown.

Bill Greene <billgreene>
Thu 13 Oct 2016 08:17:33 PM UTC, comment #5: 

We are not likely to change the way that errors are thrown in the 4.2 release now, the code base has been vastly simplified and modified to work with exceptions rather than the old harder to maintain mechanism.

Short of reworking the entire error handling system again, is there anything that can be done about this?

My understanding of how Octave and mkoctfile have always worked was that it is best to use the same compiler and compiler options for building both Octave and oct files.

Mike Miller <mtmiller>
Group Member
Sun 09 Oct 2016 12:42:43 PM UTC, comment #4: 


>Maybe something in the compatibility
>between the two compilers and how exceptions are thrown/caught?


My understanding is that this is generally a problem between different
C++ compilers. After googling around and also experimenting, I have not
been able to find a C++ exception type that can be thrown by a VC++ DLL
and caught by a MinGW main program.

I believe that the setjmp/longjmp mechanism used in Octave 4.0 for
implementing mexErr* was superior to the C++ exceptions used in 4.2.
I think it is perfectly reasonable to tell users that any exception
thrown in a mex module should also be caught in that module. So
having Octave itself throw exceptions in the mexErr* functions is a
bad design decision IMHO.

By the way, matlab is built with VC++ on windows. But they do support
writing mex functions with MinGW by, presumably, not throwing exceptions
in the mexErr* functions.


Bill Greene <billgreene>
Sun 09 Oct 2016 01:38:28 AM UTC, comment #3: 

Yes, errors in Octave are now implemented using exceptions which are thrown and caught by the interpreter.

It sounds like you are saying that compiling a mex file with mkoctfile (with gcc) works fine, but compiling it with the Visual compiler causes Octave to crash because of an uncaught exception. Maybe something in the compatibility between the two compilers and how exceptions are thrown/caught?

If this used to work, it was probably entirely by accident. Can you figure out if something needs to be done differently to compile a mex file with the Visual compiler to make exceptions work? If not this is likely to be closed as invalid because it's not clear that Octave is doing anything wrong.

Mike Miller <mtmiller>
Group Member
Sat 08 Oct 2016 08:17:40 PM UTC, comment #2: 

I'm using VS Express 2013.

I'm almost certain this change in behavior is due to a
change to the way errors are handled in mex.cc. The
routine mexErrMsgIdAndTxt calls verror_with_id(); eventually
a C++ exception is thrown which is not caught and so
causes Octave to terminate.

I have a moderately large C++ application that builds and
executes fine-- unless an error message routine is called.

Bill Greene <billgreene>
Sat 08 Oct 2016 06:19:28 PM UTC, comment #1: 

Can you provide info on whicg version of VS, and the setup of the project file etc for building of the mex file ?



John Donoghue <lostbard>
Group Member
Sat 08 Oct 2016 02:15:36 PM UTC, original submission:  

With Octave 4.0.x, I was able to build mex files with Visual Studio with no problems. With 4.2.0-rc2, there apparently is now an incompatibility between the C++ exception handling in VS and Octave/MingW.

When my code calls, e.g. mexErrMsgIdAndTxt from the mex dll built with VS, Octave crashes. If I run Octave in gdb, I get the following error message:
----------------------------------------------
terminate called after throwing an instance of 'octave::execution_exception'

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete

Program received signal SIGSEGV, Segmentation fault.
0x6feaec92 in libstdc++-6!_ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base ()
   from C:\octave\Octave-4.2.0-rc2\bin\libstdc++-6.dll
-----------------------------------------------------

Not surprisingly, the mex dll works fine if built with mkoctfile. But I have found the VS GUI to be a much more convenient environment for building mex modules and am disappointed this appears to be no longer possible.

Bill Greene <billgreene>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by billgreene (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-20 mtmiller Carbon-CopyRemoved 80942 -
    2018-09-20 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 1 - Later
        Item GroupOther Feature Request
        StatusNeed Info Postponed
        Release4.2.0 dev
        SummaryVisual Studio build issue mex functions built with MSVC don't work with errors in Octave built with MinGW
    2016-11-17 mtmiller CategoryNone Interpreter
        Item GroupNone Other
        Release4.2.0-rc2 4.2.0
    2016-10-09 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code