Why do all the MEX-files in the $MATLAB/to​olbox/matl​ab/specfun​/ directory cause a segmentation violation when using Matlab 7.0 (R14) on Linux?

I can successfully use the functions that depend on the relevant MEX-files, such as:

besselmx(real('I'), 1, 2, 0)

which returns:

 ans =

    1.5906e+00

However, upon exiting MATLAB, I receive the following segmentation violation:

 -----------

 Segmentation violation detected at Fri May 14 14:03:28 2004

 ----------

 Configuration:

   MATLAB Version:   7.0.0.16822 (R14) Prerelease 2

   Operating System: Linux 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT

 2004 i686

   Window System:    .m (1768452193), display <

   Current Visual:   0x00 (class 0, depth  0)

   Processor ID:     x86 Family 15 Model 2 Stepping 6, GenuineIntel

   Virtual Machine:  Java is not enabled

   Default Charset:  UTF-8

 Register State:

   eax = 00000000   ebx = b75cbfe0

   ecx = bfff59c0   edx = 00000040

   esi = bfff593c   edi = b75d8a1c

   ebp = bfff5838   esp = bfff5838

   eip = b7584310   flg = 00010202

 Stack Trace:

   [0] libut.so:ut_allow_further_cleanup_fcn(64, 0xbfff59c0, 0xbfff6c60,

 0xb757ec12) + 16 bytes

   [1] libut.so:MWExceptions::_utCleanupControl::~_utCleanupControl ()(0xbfff59c0, 0xb6cbe13c, 0xbfff5a08, 0xb6cb9e94) + 46 bytes

   [2] libmex.so:Mlm_mex::unload_file()(0xb4b8d590, 0, 6, 0) + 464 bytes

   [3] libmwm_dispatcher.so:Mlm_file::unload_mf()(0xb4b8d590, 0xb7376300, 0xb7376a40, 0) + 30 bytes

   [4] libmwm_dispatcher.so:mdCleanupAllFcns(0xb74377a4, 0, 0xbfff6bb8, 0xb73d451d) + 183 bytes

Answer 1

[MathWorks Support Team]

This bug has been fixed for MATLAB 7.0.1 (R14SP1). For previous releases, please read below for any possible workarounds:

This has been verified as a bug in MATLAB 7.0 (R14) in the way that MATLAB handles the MEX-files in the $MATLAB/toolbox/matlab/specfun/ directory on Linux.

As a workaround, make sure that the glibc version you are using is a version that is supported. For more information on the glibc that you should use, see the link under related solutions.

One user reports that using the glibc 2.2.9 library successfully resolved this issue.