bugGNU Octave - Bugs: bug #49296, Visual Studio build issue

 
 

bug #49296: Visual Studio build issue

Submitted by:  Bill Greene <billgreene>
Submitted on:  Sat 08 Oct 2016 02:15:36 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Other
Status: Need InfoAssigned to: None
Originator Name: Open/Closed: Open
Release: 4.2.0Operating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project Administrator
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>
Project Administrator
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>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 17 Nov 2016 05:54:13 AM UTCmtmillerCategoryNone=>Interpreter
      Item GroupNone=>Other
      Release4.2.0-rc2=>4.2.0
    Sun 09 Oct 2016 01:38:28 AM UTCmtmillerStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1