Mex-file causing crash when called by Simulink model

[Kate J.]

I have a level-2 S-function written in C that I am able to successfully compile into a mex file, in combination with a custom library file that contains functions used by the C file. When I compile these files into the mex file using the verbose –v flag, I don’t see any errors or warning messages.

However, when I run my Simulink file that calls this mex-function, there is invariably a segmentation fault and Matlab crash. The error message that appears is:
-------------------------------------------------------------
This segmentation violation occurred while executing the
S-function 'controller_CMEXsfcn' in block 'Host_model/S-Function'.
A common cause of this segmentation violation is an incorrect
input port direct feedthrough setting. Each input port of the
S-function that is read (accessed) in mdlOutputs and/or
mdlGetTimeOfNextVarHit must specify that it needs its input
signal in these routines by setting direct feedthrough for
these input ports.
1) To debug your C-MEX S-function, you can enable diagnostics
by compiling the S-function source with the -g flag, e.g.,
mex -g sfunction_name.c
2) You can ask Simulink to try assuming your S-function has
direct feedthrough using:
set_param('modelname','TryForcingSFcnDF','on')
If Simulink can find a valid sorting mode that does not
result in algebraic loops involving your S-function, your
model will execute (assuming that the cause of this
segmentation violation is an incorrect direct feedthrough
setting on an input port).
See matlabroot/simulink/src/sfuntmpl_directfeed.txt
-------------------------------------------------------------

In my mdlInitializeSizes( ) function within my C code, I believe that I correctly set my 4 input ports to direct feedthrough using the code

ssSetInputPortDirectFeedThrough(S, 0, 1);
ssSetInputPortDirectFeedThrough(S, 1, 1);
ssSetInputPortDirectFeedThrough(S, 2, 1);
ssSetInputPortDirectFeedThrough(S, 3, 1);

Then, in my mdlOutputs( ) function, I refer to these 4 variables in the following way:

const real_T *var1 = (const real_T*) ssGetInputPortSignal(S,0);
const real_T *var2 = (const real_T*) ssGetInputPortSignal(S,1);
const real_T *var3 = (const real_T*) ssGetInputPortSignal(S,2);
const real_T *var4 = (const real_T*) ssGetInputPortSignal(S,3);

When I compile using the –g flag as suggested in the first portion of the error message above, the compile process completes with no comment (i.e. the >> cursor just appears, indicating no messages or errors).

When I do set_param(‘mymodelname’,’TryForcingSFcnDF’,’on’), I just get a warning message that advises me to directly set my inputs to direct feedthrough (which, shown in the code above, I believe I already do).

Mathworks Technical Support warned that my mdlUpdate( ) function is empty; however, from the documentation, I see that this function is optional, and I don’t believe that I need to update the model, for the purposes of my system.

Beyond the advice in the error message above, I’m not sure what else might be wrong with my level-2 s-function C code that eventually gets compiled into the mex file. Can anyone recognize a problem with the above code (or potentially with some other portion of my C code), that would allow the mex file to compile with no errors, but then cause a crash when the mex file is called by my Simulink file? Thanks for your input.

[Kate J.]

One additional question: Is there any functional difference whether I manually start my Simulink model running (by clicking the model's 'play' button), or whether I run it via a command within an m-file? I vaguely recall from the past that there was some prohibition against manually starting the model running; but I can't remember what the reason was, and how valid this prohibition really is.

Currently, for debugging purposes, I am manually starting my Simulink model running. Eventually, I plan to remotely start it running via my m-file. Does it matter? Could my manual starts of the model possibly be causing this crash behavior?

[Stephen]

I'm running into this problem as well. Have you made any progress?

I'm not the only developer, so I don't know what might be causing the issue, but here are some details: there are lots of model references in my sim, and many of the signals between model references are buses. I get a segmentation fault whether I press play or start the sim from within an m-file. The sim ran fine until I incorporated some configuration set changes given to me by someone else, and there might be other changes I missed, because it's so hard to merge mdl file changes. These changes are necessary in part to get RTW to compile the sim instead of generating code only.

[Kate J.]

Stephen, I did end up solving this problem for my system. A Mathworks engineer had recommended that I "Attach" my c-mex s-function code to the Matlab debugger (after you open your code within Matlab, you can choose Attach from the top menu -- sorry that I don't have access to Matlab right now, so I can't recall which drop-down menu this choice belongs to; when you run the code, the debugger should stop at the problematic line), and this revealed that several of my function calls were problematic and causing the crash behavior. So, for my system, the problem turned out to be a problem with the usage of my custom-coded functions.

Hoping you're able to resolve your own problem using the debugger.

[He Jia]

Hey, would you please explain to me again? You said 'attach', but I didn't find this button. I have encountered the same problem when I was running my simulink. It says 'This segmentation violation occurred while executing the
S-function 'adm1_DAE0_phenol' in block 'ADM1/ADM2/ADM1'.

A common cause of this segmentation violation is an incorrect

input port direct feedthrough setting.'
This simulink just crashed, I don't know what to do. Thanks a lot.

[Kate J.]

Hi, He Jia,

I was mistaken above when I said that "Attach" was an option in the Matlab menus; rather, I just checked this, and what I did was open my c-mex s-function code using Microsoft Visual C++ 2008 Express Edition (basically, just double-clicked on my code file within my working directory, once I had this editor installed); within that editor, you can select the top Debug menu --> Attach to Process --> select Matlab from the displayed list --> click Attach. If you're using a different version of editor, the exact sequence of menu selections may differ slightly, but the same functionality should be available for any relatively recent MS C/C++ editor.

Hope this helps! Let me know if you need any other clarifications.

[He Jia]

I have found my problems with my matlab code. Thanks a lot!

[isha...@gmail.com]

On Tuesday, April 17, 2012 at 9:49:06 AM UTC-4, He Jia wrote:
> I have found my problems with my matlab code. Thanks a lot!

I know it is been long time you solved the issue..Do you remember how do you solve this? because I am getting the same error as

''''

This segmentation violation occurred while executing the

S-function 'fileNameofmyCcode' in block 'A'.

A common cause of this segmentation violation is an incorrect

input port direct feedthrough setting. Each input port of the
S-function that is read (accessed) in mdlOutputs and/or
mdlGetTimeOfNextVarHit must specify that it needs its input
signal in these routines by setting direct feedthrough for
these input ports.

Another cause can be incorrect memory accesses which occur
when your code accesses beyond the end of an array. For example
if you access input port 5 and in mdlInitializeSizes specify
that you only have 4 input ports.

'''''