bugGNU Octave - Bugs: bug #67163, loading dynare (mex?) compiled by...

 
 

bug #67163: loading dynare (mex?) compiled by older octave crashes octave

Submitter:  Dmitri A. Sergatskov <dasergatskov>
Submitted:  Tue 27 May 2025 10:44:10 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Release: 
Operating System:  * Any Fixed Release:  10.2.0
Planned Release:  10.2.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 13 Jun 2025 04:09:13 PM UTC, comment #21: 

I agree. All that was left is probably fixed in the Dynare repository now.

Markus Mützel <mmuetzel>
Group administrator
Fri 13 Jun 2025 03:35:31 PM UTC, comment #20: 

I think we can close this now?!

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 02 Jun 2025 07:50:39 AM UTC, comment #19: 


> With this patch Octave cannot use any Dynare's mex files.


That is very likely because Dynare doesn't use `mkoctfile` as the compiler/linker driver when building .mex files.
The `.mex` files of Dynare haven't been built correctly before this change either. But Octave didn't detect that. Now it does.

There isn't much (or nothing at all) that Octave can do about that. That needs to be fixed in the downstream build rules.

Markus Mützel <mmuetzel>
Group administrator
Sun 01 Jun 2025 07:55:49 PM UTC, comment #18: 

With this patch Octave cannot use any Dynare's mex files.
See:
https://octave.discourse.group/t/dynare-crashes-octave/6543/27

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 May 2025 08:03:27 AM UTC, comment #17: 

And it's up again.

Link to the changeset:
https://hg.savannah.gnu.org/hgweb/octave/rev/0fbcf917e433

Marking as ready for test (for the CI).

Markus Mützel <mmuetzel>
Group administrator
Thu 29 May 2025 07:59:58 AM UTC, comment #16: 


> it appears that octave was loading the older `liboctinterp` library? Should this NOT be possible?


Shared libraries are realized (slightly or largely) differently on different operation systems. I don't know how they are realized on macOS. But my interpretation of the originally reported error is that it wasn't Octave (directly) which caused the operating system to load the older version of liboctinterp. It was the .mex file.
There probably isn't much that Octave can do to prevent these "indirect dynamic loads" - apart from trying to prevent loading modules for which it can somehow infer that they will cause loading incompatible libraries.

The proposed patch seems to achieve that. Thank you for testing.

I was mid-push when Savannah's Mercurial went down. I hope that didn't leave the repository in a bad state.


Markus Mützel <mmuetzel>
Group administrator
Wed 28 May 2025 06:22:12 PM UTC, comment #15: 

With the patch (and having octave 9.4 installed):

octave:1> pkg load statistics
octave:2> addpath /opt/homebrew/Cellar/dynare/6.3/lib/dynare/matlab
warning: function /opt/homebrew/Cellar/dynare/6.3/lib/dynare/matlab/+identification/display.m shadows a built-in function
warning: function /opt/homebrew/Cellar/dynare/6.3/lib/dynare/matlab/+identification/display.m shadows a built-in function
octave:3> dynare Model6
warning: function /opt/homebrew/Cellar/dynare/6.3/lib/dynare/matlab/+identification/display.m shadows a built-in function
warning: X13 binary is not available.
If you are under Debian or Ubuntu, you can install it through your package manager, with 'apt install x13as'.
If you are under Windows or macOS, this probably means that you did not install the dseries toolbox through an official package.
Starting Dynare (version 6.3).
Calling Dynare with arguments: none
Starting preprocessing of the model file ...
WARNING: in the 'steady_state_model' block, variable 'Dataitmobs' is not assigned a value
WARNING: in the 'steady_state_model' block, variable 'Dataitinobs' is not assigned a value
WARNING: in the 'steady_state_model' block, variable 'Dataitcobs' is not assigned a value
Found 30 equation(s).
Evaluating expressions...
Computing static model derivatives (order 1).
Normalizing the static model...
Finding the optimal block decomposition of the static model...
8 block(s) found:
  7 recursive block(s) and 1 simultaneous block(s).
  the largest simultaneous block has 13 equation(s)
                                 and 13 feedback variable(s).
Computing dynamic model derivatives (order 2).
Normalizing the dynamic model...
Finding the optimal block decomposition of the dynamic model...
7 block(s) found:
  6 recursive block(s) and 1 simultaneous block(s).
  the largest simultaneous block has 13 equation(s)
                                 and 13 feedback variable(s).
Preprocessing completed.
Preprocessing time: 0h00m00s.
error: No SOVERSION found in .mex file function 'num_procs'.
       This can lead to incorrect results or other failures
       you can fix this problem by recompiling this .mex file
error: called from
    default_option_values at line 73 column 1
    global_initialization at line 136 column 5
    driver at line 20 column 1
    dynare at line 308 column 5
octave:4>


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 May 2025 06:13:50 PM UTC, comment #14: 

I guess i confuse myself with ABI vs API stability of MEX.
But then another issue, it appears that octave was loading the older `liboctinterp` library? Should this NOT be possible?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 May 2025 06:09:59 PM UTC, comment #13: 

Thinking about it, you probably wouldn't find any symbols that are only used in .mex files that have been compiled in older versions of Octave. Instead you would probably need to look at the RPATH information that might be stored in those .mex files (or whatever other mechanism is used by any supported OS).

All of that sounds overly complicated if just checking for the presence of one symbol should suffice.

> I.e. it should work with different versions of octave and may be even with matlab.


We are hoping that .mex files will start to be compatible between Octave 10 and later versions. But while the .mex file interface should be API compatible to Matlab, we never cared about ABI compatibility. So, it won't be possible to share the same binaries between Octave and Matlab. (But it is possible to share the same source code.)

Markus Mützel <mmuetzel>
Group administrator
Wed 28 May 2025 05:55:57 PM UTC, comment #12: 

We know how different versions of Octave build .mex files. So, we know that linking to liboctinterp and exporting the `__octave_mex_soversion__` symbol are mutually exclusive.

It is much easier to check whether one specific symbol is exported compared to whether any of a large set of functions might be used in a library. (Fwiw, I'm not sure whether it would be possible to use dlsym for such a test.)
Additionally, we are already checking for the value of that exported symbol. So, we are already checking whether it was exported or not. The proposed patch just uses the result from that check and emits an error if it is missing.

Are you worried that some users might use functions from Octave's (C++) API in .mex files? While that might be possible in general, that is not a supported use case. (And I guess that the vast majority of .mex file sources are written to be compatible with Matlab anyway. So, they won't use Octave-specific functions in any case.)


Markus Mützel <mmuetzel>
Group administrator
Wed 28 May 2025 05:38:53 PM UTC, comment #11: 


comment #9:

>
> Like jwe already wrote, we cannot load .mex files that do not export the `__octave_mex_soversion__` symbol in Octave 10 or later.


That is what i do not understand. I thought the idea is that MEX is a universal interface, version-agnostic. I.e. it should work with different versions of octave and may be even with matlab.

The older version of octave's mex were linked against Octave's libraries and thus were ABI locked to this Octave version.

This is why my proposal is to just check that MEX file is not linked to libinterp (by checking for libinterp specific symbols).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 May 2025 05:18:30 PM UTC, comment #10: 

I meant something like that (presumably in oct-shlib.cc , untested):


void *test_interp_sym = dlsym (m_library, "install_builtin_functions");
if (test_interp_sym)
{
  // Bad: this plugin links directly to liboctinterp
  dlclose (m_library);
  m_library = nullptr;
  (*current_liboctave_error_handler)
    ("%s: plugin links against internal Octave libraries (liboctinterp). "
     "This file is incompatible with Octave >= 10 and cannot be loaded safely.",

     m_file.c_str ());
}


I will test you patch shortly...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 May 2025 05:12:00 PM UTC, comment #9: 


> Can you do a check that loaded MEX has symbols that are from liboctinterp and should not be in libmex?


Could you please elaborate what you mean by that?

If your question is whether it is possible to check whether the .mex file library was linked (directly) with liboctinterp: It should be possible to do that with tools like `ldd`.
But I don't think that we need to do that here.

Like jwe already wrote, we cannot load .mex files that do not export the `__octave_mex_soversion__` symbol in Octave 10 or later. I'm hoping that the patch would lead to an error message in that case. So, it would prevent that crash from happening by not attempting to load the .mex file function in the first place.


Markus Mützel <mmuetzel>
Group administrator
Wed 28 May 2025 04:01:44 PM UTC, comment #8: 

Can you do a check that loaded MEX has symbols that are from liboctinterp and should not be in libmex?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 May 2025 03:48:31 PM UTC, comment #7: 

"So we just need a check that MEX was compiled with octave 9.4 and earlier and refuse to load it?"

I don't know of any way to do exactly that.  But the patch the Markus posted does effectively the same thing since earlier versions of Octave's mkoctfile (AKA mex) function to compile MEX files did not embed the SOVERSION of liboctmex in the compiled MEX file.  So if that info is missing in the MEX file, we refuse to load it.

John W. Eaton <jwe>
Group administrator
Wed 28 May 2025 03:40:45 PM UTC, comment #6: 

OK, I guesss we half-way there. So we just need a check that MEX was compiled with octave 9.4 and earlier and refuse to load it?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 May 2025 03:26:37 PM UTC, comment #5: 

.mex files were linking to liboctinterp and liboctave in Octave 9 or earlier. The API of these libraries isn't guaranteed to be stable between (major) versions of Octave. Their soversion changes (at least once) for each major version of Octave. So, .mex files have been version specific in these versions of Octave.

Starting with Octave 10, we have a new library liboctmex to which .mex are linking. The soversion of liboctmex will likely (or hopefully) not change between major versions of Octave. So, .mex files that are built with Octave 10 should be working also with Octave 11 (or later).

Since the .mex files that are bundled with the Dynare installer have been built with Octave 9.4.0, they are still version specific.

Markus Mützel <mmuetzel>
Group administrator
Wed 28 May 2025 03:18:32 PM UTC, comment #4: 

I have not tested the patch yet. Should not MEX be version agnostic?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 May 2025 12:14:51 PM UTC, comment #3: 

Oops. There was an issue with the previous patch. Please test the ...-v2.patch.

(file #57249)

Markus Mützel <mmuetzel>
Group administrator
Wed 28 May 2025 12:03:39 PM UTC, comment #2: 

I also tested with the latest unstable version of Dynare (7-unstable-2025-05-23-1742-a3f2a389) with the same result:
The .mex file doesn't load in Octave 10.1.0 (as expected) and it doesn't crash Octave.

Markus Mützel <mmuetzel>
Group administrator
Wed 28 May 2025 11:51:13 AM UTC, comment #1: 

I cannot reproduce on Windows with Octave 10.1.0.

I attempted by downloading the Model6.mod file from that Discourse thread (also attached here) and running the following in Octave:

>> addpath C:\dynare\6.3\matlab
warning: function C:\dynare\6.3\matlab\+identification\display.m shadows a built-in function
warning: function C:\dynare\6.3\matlab\+identification\display.m shadows a built-in function
>> dynare Model6
warning: function C:\dynare\6.3\matlab\+identification\display.m shadows a built-in function

warning: This version of Octave is not supported. Consider installing version 9.4.0 of Octave
from www.octave.org, otherwise m files will be used instead of precompiled mex files and some
features, like solution of models approximated at third order, will not be available.
warning: called from
    dynare at line 78 column 9


Starting Dynare (version 6.3).
Calling Dynare with arguments: none
Starting preprocessing of the model file ...
WARNING: in the 'steady_state_model' block, variable 'Dataitmobs' is not assigned a value
WARNING: in the 'steady_state_model' block, variable 'Dataitinobs' is not assigned a value
WARNING: in the 'steady_state_model' block, variable 'Dataitcobs' is not assigned a value
Found 30 equation(s).
Evaluating expressions...
Computing static model derivatives (order 1).
Normalizing the static model...
Finding the optimal block decomposition of the static model...
8 block(s) found:
  7 recursive block(s) and 1 simultaneous block(s).
  the largest simultaneous block has 13 equation(s)
                                 and 13 feedback variable(s).
Computing dynamic model derivatives (order 2).
Normalizing the dynamic model...
Finding the optimal block decomposition of the dynamic model...
7 block(s) found:
  6 recursive block(s) and 1 simultaneous block(s).
  the largest simultaneous block has 13 equation(s)
                                 and 13 feedback variable(s).
Preprocessing completed.
Preprocessing time: 0h00m00s.
error: opening the library 'C:\dynare\6.3\mex\octave\win64\num_procs.mex' failed (error 126): Das angegebene Modul wurde nicht gefunden.
error: called from
    default_option_values at line 73 column 1
    global_initialization at line 136 column 5
    driver at line 20 column 1
    dynare at line 308 column 5
>>


The German error message basically says that a necessary module could not be loaded.

In this case, this is very likely because "num_procs.mex" is linked to "liboctinterp-12.dll". But the soversion suffix of that library is different in Octave 10.1.0: "liboctinterp-13.dll".


In the macOS crash dump, it looks like it is attempting to use symbols from liboctinterp.13.dylib and from liboctinterp.12.dylib. That shouldn't be happening.

I thought I tested whether the liboctmex SOVERSION was checked when trying to load a .mex file. But maybe, I did that only by incrementing the SOVERSION locally and forgot to test that with older .mex files that don't export that SOVERSION identifier.

Does the attached patch prevent the crash on macOS?

(file #57247, file #57248)

Markus Mützel <mmuetzel>
Group administrator
Tue 27 May 2025 10:44:10 PM UTC, original submission:  

If i use selfcompile octave 11 and try to load and execute some dynare code (which appears to be using mex), it crashes octave.
The brash dump (on MacOS) is attached (file dynare_crash.txt.gz)

I used "dynare" package from homebrew (compiled against 9.4) and tried to load it in 11.0.
(It works fine if I used octave 9.4)

See also for report of crash on Windows.
https://octave.discourse.group/t/andrews-1993-test-for-structural-breaks-for-irelands-2007-model/6188/46?u=dasergatskov.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #57247:  Model6.mod added by mmuetzel (4KiB - video/mpeg)
file #57244:  dynare_crash.txt.gz added by dasergatskov (20KiB - application/x-gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by dasergatskov (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-13 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 10.2.0
    2025-05-29 mmuetzel StatusPatch Submitted Ready For Test
        Planned ReleaseNone 10.2.0
    2025-05-28 mmuetzel Attached File- Added bug67163-mex-no-soversion-v2.patch, #57249
    2025-05-28 mmuetzel StatusNone Patch Submitted
    2025-05-28 mmuetzel Attached File- Added Model6.mod, #57247
        Attached File- Added bug67163-mex-no-soversion.patch, #57248
    2025-05-27 dasergatskov Attached File- Added dynare_crash.txt.gz, #57244

    Back to the top

    Powered by Savane 3.15-26b0.
    Corresponding source code