Differences between the executing environment of mex functions and s functions
3 次查看(过去 30 天)
显示 更早的评论
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?
1 个评论
Richard Zappulla
2017-3-30
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.
回答(1 个)
另请参阅
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!