Segmentation fault when starting matlab

Hello,

I successfully installed and activated MATLAB R2015b. But starting gives just a segfault:

~/software/MATLAB/R2015b/bin % ./matlab
MATLAB is selecting SOFTWARE OPENGL rendering.
[1]    5956 segmentation fault (core dumped)  ./matlab

Some system information:

% uname -a
Linux asaru 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015 x86_64 GNU/Linux

Graphic driver is xf86-video-intel: https://www.archlinux.org/packages/extra/x86_64/xf86-video-intel/

Any more information I will be happy to provide.

Thanks!

[M L]

I encountered the same error and cannot solve it, too. (<http://jp.mathworks.com/matlabcentral/answers/243816-segmentation-fault-when-starting-matlab>)

You can run `matlab -Dgdb` and see if it gives you more information.

Answer 1

[Eric]

You may try linking /usr/lib64/libncursesw.so.6 to MATLAB_INSTALL_PATH/bin/glnxa64/libncurses.so.5.

[Daniel Hodapp]

Thank you! This worked for me. For a little bit I thought I would have to run the program in windows, at least until a fix was made.

[Cengiz Gunay]

Thank you, this worked on my brand new Manjaro installation, too.

[Christoph Wanasek]

Thanks a lot for sharing this tip!

Works perfectly fine in my case! (on Manjaro Linux 15.12)

[Tibor Stanko]

Thanks! Worked perfectly on Fedora 24.

[Cody Johnson]

Also worked for me. I guess the installation just skips linking to libncursess if its not version 5.

Answer 2

[Yuichi Tadokoro]

I had the same issue on my Intel laptop running Arch Linux. In my case, it was a problem with ncurses that had been updated recently.

Downgrading ncurses to 5.9.7 (and several packages depend on ncurses-6.x to the previous versions) solved the problem.

Creating symlink from /usr/lib/libncurses.so to /usr/lib/libncurses.so.5 may be another workaround, yet this is a dirty solution.

Hope this helps!!

Answer 3

[James Fallon]

I tried symlinking all of the libncurses .6 to .5 but this doesn't seem to fix the problem. Looks like the only solution, as suggested by Yuichi, is to roll back to 5.9.7 and wait for an upstream fix.

edit 4: Now you can just install ncurses5-compat-libs from the aur instead of following edit 3

edit 3: Greatly simplified solution method by Jonhoo: https://wiki.archlinux.org/index.php/Matlab#Segmentation_Fault_on_startup

Wiki: "If after a recent upgrade (libncurses to v 6.x) matlab stops working, you will need to make the old 5.9.7 version of ncurses available to matlab. To achieve this, you should copy the old ncurses library files back into /usr/lib. (permanently rollingback to 5.9.7 is not recommended as this causes many programs such as vi, vim, bash not to work) IE: "

 mkdir tmp; cd tmp
 wget http://seblu.net/a/arm/month/core/os/x86_64/ncurses-5.9-7-x86_64.pkg.tar.xz
 xzdec ncurses-5.9-7-x86_64.pkg.tar.xz | tar xv
 sudo find usr/lib -iname '*5*' -exec cp "{}" /usr/lib \;

Answer 4

[pgzh]

EDIT

Pay attention what file you are linking to what filename!

   # ln -s /lib/libncursesw.so.5 matlab/bin/glnxa64/libncurses.so.5

worked for me, too!

One has to link the libncursesw (with a 'w') to just libncurses (without the w)!

Thank you very much Zilong Tan !

----

That didn't work for me. My matlab installation path is /opt/matlab. I tried

# ln -s /lib/libncursesw.so.6 /opt/matlab/bin/glnxa64/libncursesw.so.5

and

# ln -s /lib/libncursesw.so.5 /opt/matlab/bin/glnxa64/libncursesw.so.5

after installing ncurses5-compat-libs from AUR. BTW: Arch uses the following symlinks:

/lib -> /usr/lib
/lib64 -> /usr/lib
/usr/lib -> /usr/lib64

So I din't link to the wrong directory.

Also

$ export LD_PRELOAD=/lib/libncursesw.so.5

before starting matlab didn't change anything.

That was a good idea since ncurses was recently updated, but actually the MATLAB binary in glnxa64 isn't linked to libncurses. Any other ideas?

Answer 5

[Walter Roberson]

You should contact Mathworks for free installation support.

Answer 6

[Tiago Rodrigues]

/usr/local/MATLAB/R2015b/bin/matlab -nodisplay and /usr/local/MATLAB/R2015b/bin/matlab -nosoftwareopengl gives me the same error so it shouldn't be graphics/opengl related

Answer 7

[Mads Paulsen]

getting same error just on arch linux, think it might be related to a recent pacman -Syu

Answer 8

[pgzh]

I am suffering from the same problem since doing a 'pacman -Syu' and rebooting the system yesterday on Arch Linux x86-64. I am also using xf86-video-intel, but am not convinced that this is graphics-related. If anyone comes up with a solution or has contacted Mathworks' installation support, please keep me informed about any possible solutions.

[M L]

You can check your pacman logs (should be /var/log/pacman) for recently updated packages

Answer 9

[James Fallon]

Same problem here on clean arch linux install for

uname -a
Linux myhostname 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015 x86_64 GNU/Linux

% matlab
MATLAB is selecting SOFTWARE OPENGL rendering.
zsh: segmentation fault (core dumped)  matlab

My graphics (using xf86-video-intel):

% lspci | grep -e VGA -e 3D
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

The cause appears to be this specific binary: '/{MATLAB install directory}/R2015b/bin/glnxa64/MATLAB' (e.g. /home/foo/bin/MATLAB/R2015b/bin/glnxa64/MATLAB or /usr/local/bin/MATLAB/R2015b/bin/glnxa64/MATLAB etc.)

After poking through the scripts that launch matlab, I did find some suspicious code:

if [ 1 -eq 1 ]; then

-_- Hopefully someone not on a clean install can roll back some packages to find the cause of the problem? xf86-video-intel can't be a direct cause ofthe problem ( I think ) since it was last updated July 22.

Answer 10

[pgzh]

One more thing that makes me wonder is:

$ ldd glnxa64/MATLAB
        linux-vdso.so.1 (0x00007fff8c1ef000)
        libmwi18n.so => /opt/matlab/bin/glnxa64/libmwi18n.so (0x00007f9ff9bb1000)
        libmwmvm.so => /opt/matlab/bin/glnxa64/libmwmvm.so (0x00007f9ff96b1000)
        libmwcpp11compat.so => /opt/matlab/bin/glnxa64/libmwcpp11compat.so (0x00007f9ff949c000)
        libstdc++.so.6 => /opt/matlab/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6 (0x00007f9ff9195000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f9ff8e97000)
        libgcc_s.so.1 => /opt/matlab/bin/glnxa64/../../sys/os/glnxa64/libgcc_s.so.1 (0x00007f9ff8c82000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f9ff8a65000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f9ff86c1000)
        libmwresource_core.so => /opt/matlab/bin/glnxa64/libmwresource_core.so (0x00007f9ff84c0000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f9ff82bc000)
        libboost_date_time.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_date_time.so.1.49.0 (0x00007f9ff80ab000)
        libboost_filesystem.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_filesystem.so.1.49.0 (0x00007f9ff7e8c000)
        libboost_system.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_system.so.1.49.0 (0x00007f9ff7c89000)
        libboost_thread.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_thread.so.1.49.0 (0x00007f9ff7a6e000)
        libexpat.so.1 => /opt/matlab/bin/glnxa64/libexpat.so.1 (0x00007f9ff7846000)
        libicudata.so.54 => /opt/matlab/bin/glnxa64/libicudata.so.54 (0x00007f9ff5e1a000)
        libicuuc.so.54 => /opt/matlab/bin/glnxa64/libicuuc.so.54 (0x00007f9ff5a8e000)
        libicui18n.so.54 => /opt/matlab/bin/glnxa64/libicui18n.so.54 (0x00007f9ff563f000)
        libicuio.so.54 => /opt/matlab/bin/glnxa64/libicuio.so.54 (0x00007f9ff5432000)
        libtbb.so.2 => /opt/matlab/bin/glnxa64/libtbb.so.2 (0x00007f9ff51e7000)
        libtbbmalloc.so.2 => /opt/matlab/bin/glnxa64/libtbbmalloc.so.2 (0x00007f9ff4f95000)
        libmwms.so => /opt/matlab/bin/glnxa64/libmwms.so (0x00007f9ff4957000)
        libut.so => /opt/matlab/bin/glnxa64/libut.so (0x00007f9ff4697000)
        libmwfl.so => /opt/matlab/bin/glnxa64/libmwfl.so (0x00007f9ff4297000)
        libmx.so => /opt/matlab/bin/glnxa64/libmx.so (0x00007f9ff3f0d000)
        libmwmlutil.so => /opt/matlab/bin/glnxa64/libmwmlutil.so (0x00007f9ff382e000)
        libboost_iostreams.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_iostreams.so.1.49.0 (0x00007f9ff3619000)
        libboost_log.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_log.so.1.49.0 (0x00007f9ff3341000)
        libboost_serialization.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_serialization.so.1.49.0 (0x00007f9ff30c9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9ff9e97000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007f9ff2ec1000)
        libboost_chrono.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_chrono.so.1.49.0 (0x00007f9ff2cba000)
        libboost_regex.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_regex.so.1.49.0 (0x00007f9ff299f000)
        libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f9ff2767000)
        libboost_signals.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_signals.so.1.49.0 (0x00007f9ff254f000)
        libunwind.so.8 => /opt/matlab/bin/glnxa64/libunwind.so.8 (0x00007f9ff2330000)
        libssl.so.1.0.0 => /opt/matlab/bin/glnxa64/libssl.so.1.0.0 (0x00007f9ff20c5000)
        libcrypto.so.1.0.0 => /opt/matlab/bin/glnxa64/libcrypto.so.1.0.0 (0x00007f9ff1ce2000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f9ff1acc000)
        libavrocpp.so.1.7.5.0 => /opt/matlab/bin/glnxa64/libavrocpp.so.1.7.5.0 (0x00007f9ff17ee000)
        libboost_program_options.so.1.49.0 => /opt/matlab/bin/glnxa64/libboost_program_options.so.1.49.0 (0x00007f9ff1590000)

So the matlab binary does not rely on many libraries on the system, but mostly uses self-provided libraries. I can't quite explain why a upgrade of any libraries on the system would cause matlab to behave differently because of this.

I am running a custom Linux kernel and did not change it since MatLab was starting successfully, so it can hardly be kernel related.

Maybe it's a graphics issue after all, I recall mesa being updated to 10.6.7 with the update that broke MatLab. mesa provides 3D acceleration (i.e. OpenGL) for Intel graphics hardware. If I find the time I'll try downgrading mesa to the previous version and report back.

Is anyone with non-Intel graphics hardware or not using Arch Linux affected by this problem?