Segmentation fault when starting matlab

32 views (last 30 days)
Florian Lindner
Florian Lindner on 18 Sep 2015
Commented: Cody Johnson on 28 Jan 2017
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!
  1 Comment
M L
M L on 20 Oct 2015
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.

Sign in to comment.

Answers (10)

Eric
Eric on 21 Sep 2015
You may try linking /usr/lib64/libncursesw.so.6 to MATLAB_INSTALL_PATH/bin/glnxa64/libncurses.so.5.
  5 Comments
Cody Johnson
Cody Johnson on 28 Jan 2017
Also worked for me. I guess the installation just skips linking to libncursess if its not version 5.

Sign in to comment.


Yuichi Tadokoro
Yuichi Tadokoro on 20 Sep 2015
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!!

James Fallon
James Fallon on 20 Sep 2015
Edited: James Fallon on 20 Sep 2015
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 \;

pgzh
pgzh on 23 Sep 2015
Edited: pgzh on 23 Sep 2015
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?

Walter Roberson
Walter Roberson on 18 Sep 2015
You should contact Mathworks for free installation support.

Tiago Rodrigues
Tiago Rodrigues on 18 Sep 2015
/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

Mads  Paulsen
Mads Paulsen on 19 Sep 2015
getting same error just on arch linux, think it might be related to a recent pacman -Syu

pgzh
pgzh on 19 Sep 2015
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.
  1 Comment
M L
M L on 20 Oct 2015
You can check your pacman logs (should be /var/log/pacman) for recently updated packages

Sign in to comment.


James Fallon
James Fallon on 19 Sep 2015
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.

pgzh
pgzh on 19 Sep 2015
Edited: pgzh on 19 Sep 2015
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?

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!