Why does my Fortran MEX file with internal subroutines crash on Linux with MATLAB R2025a

My Fortran MEX file contains an internal subroutine that is used as an argument to another subroutine. This code worked on previous versions of MATLAB, but is crashing on R2025a. Why is there a segv fault in R25a and how can I prevent it?

Answer 1

[MathWorks Support Team]

In Fortran, using an internal subroutine as an argument to another subroutine requires that the operating system allows execution of program code in the program’s “stack” memory region. This ability is typically controlled via the executable stack flag, or execstack, in the program’s ELF header. In R2024b and earlier, the execstack flag of the MATLAB executable was enabled, by default. However, in R2025a, and going forward, the execstack flag of the MATLAB executable will not be enabled. This change is for security reasons, as having the execstack flag enabled poses a security risk. This change only affects Linux machines.

Because of this change, any MEX function, or one of it's dependencies, that requires an executable stack will also cause MATLAB to crash. Similarly, any external language (C, C++, Java, Python, Fortran), or one of it's dependencies, that requires an executable stack will also cause MATLAB to crash. 

The crash can be avoided by following one of the workarounds below, depending on which version of GLIBC your system is using. You can use the "ldd" command in a Linux terminal to determine which version of GLIBC your system is using. See the command below with example output.

$ ldd --version
ldd (Ubuntu GLIBC 2.41-6ubuntu1.1) 2.41

GLIBC 2.42 and greater

Note: This also works for some distributions with glibc-2.41, including Debian 13 and Fedora 42.

The executable stack can be enabled at runtime by setting the following environment variable.

GLIBC_TUNABLES=glibc.rtld.execstack=2

Do not set this globally in your shell, as this may introduce security risks into other programs. Instead, set this variable only when launching MATLAB.  This can be done with a shell script, for example:

#!/bin/sh
GLIBC_TUNABLES=glibc.rtld.execstack=2
export GLIBC_TUNABLES

<PATH_TO_MATLAB_INSTALL>/bin/matlab "$@"

GLIBC 2.41

The only workaround is to enable the execstack flag for the MATLAB executable before launching MATLAB.  Important note:  Enabling the executable stack could pose a security risk. 

$ execstack -s <path_to_MATAB_exe>

Note that enabling the execstack flag requires write permission on the MATLAB executable and only needs to be done once - it does not need to be executed each time before launching MATLAB.

GLIBC 2.39 and earlier

Compile the MEX code with the following 'LDEXECSTACK=' flag. For example

>> mex('mycode.F90', 'LDEXECSTACK=');

[James Tursa]

I have never heard of conforming regular Fortran code somehow compiling such that part of the code itself is trying to run from stack memory. Can you please post an example that demonstrates this? I.e., complete source code.