Differences between the executing environment of mex functions and s functions

Hi all,

I have a problem that has stumped me for nearly two weeks. I have a library that presents a C interface, for the purpose of sending Google protobuf serial information across a network socket. The library works great when called via a C driver program. It also works great when I encapsulate it as a MEX file. And it reliably segfaults when called from a type 2 S function file (but only on Linux - calling it on a Mac as an S function also works beautifully).

The only information from the stack trace is that the segfault occurs in libstdc++.so.6, in a library call that is name mangled as "resizeEmc". It seems to occur even before any of the code in the S function is actually executed - it's happening during the load or library initialization process. And it happens even if I comment out all of the code in the S Function that actually calls the library code; all that is required for the crash is for there to be a linker dependency on the library in the compiled .mexa64 file.

So, my question: what is the difference between the executing environment of a plain vanilla MEX file and a Simulink S Function? Does one handle dynamically allocated memory, or global static variables in the library, or something, differently from the other? Is there a difference in how dynamic library dependencies get resolved?

[Richard Zappulla]

To the best of my knowledge, vanilla MEX files run in a Java environment -- so they can leverage some functionality that you may not be able to do in say, a C S-Function.

Answer 1

[Glen]

As a followup to this, I have verified that my code works perfectly under MATLAB R2015b, but not under R2016b. I believe this indicates a bug in the R2016b version of Simulink.