Mrview - segmentationfault (core dump) + Ubuntu 16.04

OK, can you try this and see if that helps:

$ git fetch 
$ git checkout fix_alignment_for_transform_type
$ ./build

Hopefully that’ll sort out that particular issue, but I have a feeling you’ll be coming across a few more of these over the next few weeks… Please report any crashes that you encounter, we’ll see if we can apply the same fixes as here (assuming they work, of course…).

So we’ve been trying to reproduce this issue on our own systems, with no luck… To help us narrow this down, it would be great if you could give us a bit more information about your system. Specifically:

  • the output of lscpu (or cat /proc/cpuinfo if that doesn’t work)

  • the contents of your release/config file (in the MRtrix3 folder)

If you have the time, it would be great if you could also run the following:

$ git checkout master
$ ./configure -assert -debug
$ ./build
$ ./run_tests

and post the contents of the resulting testing.log file here.

To revert your installation back to how it was, once you’re done with the above:

$ ./configure
$ ./build

lscpu:

ibmi@ibmi-81645:~$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Model name:            Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Stepping:              3
CPU MHz:               4273.281
CPU max MHz:           4400,0000
CPU min MHz:           800,0000
BogoMIPS:              8000.21
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts

Release/Config file:

#!/usr/bin/python
#
# autogenerated by MRtrix configure script
#
# configure output:
#
# MRtrix build type requested: release
#
# Detecting OS: linux
# Checking for C++11 compliant compiler [g++]: 5.3.1 - tested ok
# Detecting pointer size: 64 bit
# Detecting byte order: little-endian
# Checking for variable-length array support: yes
# Checking for non-POD variable-length array support: yes
# Checking for zlib compression library: 1.2.8
# checking for Eigen 3 library: 3.2.92
# Checking shared library generation: yes
# Checking for Qt moc: moc (version 4.8.7)
# Checking for Qt qmake: qmake (version 4.8.7)
# Checking for Qt rcc: rcc (version 4.8.7)
# Checking for Qt: 4.8.7

PATH = r'/home/ibmi/mrtrix3/release/bin:/home/ibmi/mrtrix3/scripts:/home/ibmi/mrtrix3/bin:/usr/share/fsl/5.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/fsl/5.0'
obj_suffix = '.o'
exe_suffix = ''
lib_prefix = 'lib'
lib_suffix = '.so'
cpp = [ 'g++', '-c', 'CFLAGS', 'SRC', '-o', 'OBJECT' ]
cpp_flags = [ '-std=c++11', '-pthread', '-fPIC', '-march=native', '-DMRTRIX_WORD64', '-isystem', '/usr/include/eigen3', '-Wall', '-O2', '-DNDEBUG' ]
ld = [ 'g++', 'OBJECTS', 'LDFLAGS', '-o', 'EXECUTABLE' ]
ld_flags = [ '-pthread', '-lz' ]
runpath = '-Wl,-rpath,$ORIGIN/'
ld_enabled = True
ld_lib = [ 'g++', 'OBJECTS', 'LDLIB_FLAGS', '-o', 'LIB' ]
ld_lib_flags = [ '-pthread', '-shared', '-pthread', '-lz' ]
eigen_cflags = [ '-isystem', '/usr/include/eigen3' ]
moc = 'moc'
rcc = 'rcc'
qt_cflags = [ '-m64', '-pipe', '-O2', '-Wall', '-W', '-D_REENTRANT', '-DQT_NO_DEBUG', '-DQT_SVG_LIB', '-DQT_OPENGL_LIB', '-DQT_GUI_LIB', '-DQT_CORE_LIB', '-DQT_SHARED', '-isystem', '/usr/share/qt4/mkspecs/linux-g++-64', '-isystem', '/usr/include/qt4/QtCore', '-isystem', '/usr/include/qt4/QtGui', '-isystem', '/usr/include/qt4/QtOpenGL', '-isystem', '/usr/include/qt4/QtSvg', '-isystem', '/usr/include/qt4', '-isystem', '/usr/X11R6/include' ]
qt_ldflags = [ '-m64', '-Wl,-O1', '-L/usr/lib/x86_64-linux-gnu', '-L/usr/X11R6/lib64', '-lQtSvg', '-lQtOpenGL', '-lQtGui', '-lQtCore', '-lGL', '-lpthread' ]
nogui = False

OK, that’s a very similar CPU to mine, it’s 64-bit, and has all the SSE4 extensions. MRtrix3 is compiled for a 64-bit architecture, everything seems to check out OK.

So the only thing I can think of now is that there might be a bug in the particular version of Eigen that you’re running: this is actually not their stable release version, but looks to me like their 3.3 beta. @NicholasDowson also reported issues compiling on 16.04 against that version of Eigen, and reverted back to the release version to build successfully. We issued a fix to compile on that version of Eigen only yesterday… But while it fixes the compilation issue, no one has actually verified that things worked properly with that version of Eigen…

So maybe your simplest bet is to follow the instructions we’d provided to use the stable release version of Eigen, see if that fixes the problem…

1 Like

I have the testing.log … but its 3000 lines. Should I post it or send it by mail.

Just post it enclosed in [code][/code] tags - as explained in detail in @ThijsDhollander’s formatting tips post. Thanks!

Thats no all, a post is limited to 32,000 characters. I had 160,000. So…take the mail!

Sorry to Thijs, I admit…I didnt read that. I will now.

1 Like
building testing commands... OK
    running "5tt2gmwmi"... 0 of 1 passed    <-------- ERROR
    running "5tt2vis"... 0 of 1 passed    <-------- ERROR
    running "5ttedit"... 1 of 2 passed    <-------- ERROR
    running "amp2sh"... 0 of 1 passed    <-------- ERROR
    running "dirgen"... 4 of 4 passed
    running "dwi2adc"... 0 of 1 passed    <-------- ERROR
    running "dwi2fod"... 0 of 3 passed    <-------- ERROR
    running "dwi2mask"... 0 of 1 passed    <-------- ERROR
    running "dwi2noise"... 0 of 1 passed    <-------- ERROR
    running "dwiextract"... 0 of 2 passed    <-------- ERROR
    running "fixel2sh"... 0 of 1 passed    <-------- ERROR
    running "fixel2tsf"... 0 of 1 passed    <-------- ERROR
    running "fixeldivide"... 0 of 1 passed    <-------- ERROR
    running "fixelmult"... 0 of 1 passed    <-------- ERROR
    running "fixelthreshold"... 0 of 2 passed    <-------- ERROR
    running "fod2fixel"... 3 of 3 passed
    running "label2colour"... 1 of 3 passed    <-------- ERROR
    running "label2mesh"... 0 of 2 passed    <-------- ERROR
    running "labelconfig"... 0 of 2 passed    <-------- ERROR
    running "maskfilter"... 2 of 9 passed    <-------- ERROR
    running "mesh2pve"... 0 of 1 passed    <-------- ERROR
    running "meshconvert"... 10 of 10 passed
    running "mrcalc"... 0 of 4 passed    <-------- ERROR
    running "mrcat"... 0 of 6 passed    <-------- ERROR
    running "mrconvert"... 0 of 11 passed    <-------- ERROR
    running "mrcrop"... 0 of 2 passed    <-------- ERROR
    running "mrfilter"... 0 of 8 passed    <-------- ERROR
    running "mrmath"... 0 of 3 passed    <-------- ERROR
    running "mrpad"... 0 of 4 passed    <-------- ERROR
    running "mrresize"... 0 of 8 passed    <-------- ERROR
    running "mrstats"... 2 of 5 passed    <-------- ERROR
    running "mrthreshold"... 0 of 10 passed    <-------- ERROR
    running "mrtransform"... 2 of 6 passed    <-------- ERROR
    running "peaks2amp"... 0 of 1 passed    <-------- ERROR
    running "sh2amp"... 0 of 3 passed    <-------- ERROR
    running "sh2peaks"... 0 of 1 passed    <-------- ERROR
    running "sh2power"... 0 of 1 passed    <-------- ERROR
    running "sh2response"... 0 of 1 passed    <-------- ERROR
    running "shbasis"... 0 of 4 passed    <-------- ERROR
    running "shconv"... 0 of 2 passed    <-------- ERROR
    running "tck2connectome"... 0 of 3 passed    <-------- ERROR
    running "tckconvert"... 3 of 4 passed    <-------- ERROR
    running "tckgen"... 0 of 14 passed    <-------- ERROR
    running "tckmap"... 0 of 4 passed    <-------- ERROR
    running "tcknormalise"... 0 of 1 passed    <-------- ERROR
    running "tcksample"... 0 of 1 passed    <-------- ERROR
    running "tcksift"... 0 of 1 passed    <-------- ERROR
    running "tcksift2"... 0 of 1 passed    <-------- ERROR
    running "tensor2metric"... 0 of 8 passed    <-------- ERROR
    running "transformcalc"... 1 of 1 passed
    running "tsfdivide"... 1 of 1 passed
    running "tsfmult"... 1 of 1 passed
    running "tsfsmooth"... 1 of 1 passed
    running "tsfthreshold"... 2 of 2 passed
    running "voxel2fixel"... 0 of 1 passed    <-------- ERROR
    running "warpcorrect"... 0 of 1 passed    <-------- ERROR
    running "warpinit"... 0 of 1 passed    <-------- ERROR

I’ve got mrview segfaulting on Eigen 3.2.92. So it’s definitely compatibility with the beta version of Eigen that’s the issue. Unfortunately my Windows machine claims my debug build doesn’t contain debugging symbols, so I can’t dig further right now. But you should be able to revert to the stable release of Eigen to fix the issue at your end, and the devs should be able to chase up the issues with the Eigen beta in our own time.

Can you clarify the command…it cant finde the eigen library? What is-I$(pwd)?
Or do i have to install before? Maybe I am to tired to understand. :slight_smile:

→ the configure works now!

OK, good to hear. For reference, you can copy-paste the following into a terminal, having changed into the MRtrix3 folder - it should just work as-is…

wget http://bitbucket.org/eigen/eigen/get/3.2.8.tar.gz
tar xvfz 3.2.8.tar.gz 
rm -f 3.2.8.tar.gz
mv eigen-eigen-* eigen
EIGEN_CFLAGS="-isystem $(pwd)/eigen" ./configure
./build

For reference, the problem as reported in @Ralf’s testing.log output is as per the original. For example:

mrconvert: /usr/include/eigen3/Eigen/src/Core/DenseStorage.h:128: Eigen::internal::plain_array<T, Size, MatrixOrArrayOptions, 32>::plain_array() [with T = double; int Size = 12; int MatrixOrArrayOptions = 0]: Assertion `(reinterpret_cast<size_t>(eigen_unaligned_array_assert_workaround_gcc47(array)) & (31)) == 0 && "this assertion is explained here: " "http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html" " **** READ THIS WEB PAGE !!! ****"' failed.

Basically nothing works, as you see from the actual output of ./run_tests above…

1 Like

My first tests with mrview are positiv.
I try a little arround!

No worries, I’m not (too) emotionally attached to that post. :wink: …but the code tags are a super handy thing indeed!

Morning…
So, I played a little arround with fixeling and indiscriminately mrtrixing and mrviewing stuff. And it works so far… :slight_smile:
Thanks for the help. I hope “Eigen” solves the problem.

So…MRTrix is working…what do I do next? :grin:

Just ran into this yesterday evening as well (mrview segfaulting; also Ubuntu 16.04)… got me stumped for a while, until I stumbled upon these posts; the above of course fixing things. I was (unknowingly) also using the beta version of Eigen. I reckon quite a few people may start running into issues on Ubuntu 16.04; as our default installation instructions basically sets them up with the 3.3 beta of Eigen…

In my case, I was able to run mrview, but it kept segfaulting upon loading an image. Every once in a while (like 1 in 30 times or something) it did load the image; but it was a pretty consistent segfault in all other cases…

Segfaulting is one thing, but what’s more worrying is people using a beta version of the library that handles a lot of our mathematics…

Yes, that is indeed a concern. There is in fact a pull request with the fixes required to get MRtrix3 working with Eigen 3.3 beta, maybe we need to merge and see what happens… I’ve got it to a state where it passes all tests, but I have a strong suspicion there’ll be other places where it’ll fall over. The good news is the changes shouldn’t affect operation with Eigen 3.2, and when there is a failure, it should manifest as an overt crash (rather than producing a wrong result, which would be far worse…). So I think merging would be perfectly safe - at least as safe as the current state anyway.

Yes, I’m also a bit worried about this. But I reckon their beta is probably pretty close to release, and very thoroughly unit tested (although I’d have to check that). In any case, if Ubuntu are happy to provide a beta package as their default, it should be fine - and we can blame them if it turns out otherwise… :wink:

I’m away at the moment, so if anyone is feeling keen, feel free to update the branch and merge.

Hi,

Had the same issue, same fix. Just for the record. Also using Ubuntu 16.04

Thanks

Eduardo

Thanks for reporting this. However, I pushed out a commit 9 days ago that should make it safe to use the beta (now release) 3.3 version of Eigen. How recently did you last update the MRtrix3 code (with git pull)? Note that you need to re-run ./configure and then ./build for the changes to take effect. If you found you needed to downgrade Eigen even using a version of MRtrix3 later than this commit, I’d like to know about it ASAP! A quick check would be to look into your release/config file, you should find the -mno-avx option listed in the cpp_flags entry.

I’m currently trying to fix the rest of the code so we don’t need to resort to that last hack (involves disabling certain CPU optimisations, which is not ideal). It’s actually a really complex problem, but I think I’ve got a workable solution. It’s almost there, hopefully I’ll have this working properly fairly soon. But in the meantime, it should at least be safe to use any version of Eigen with the changes I made 9 days ago. Let me know if that’s not the case!