MATLAB: 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

7.0besselmxlinuxMATLABmexr14segvspecfun

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

Best Answer

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.
Related Question