Hi everyone, I’m unsure where this should be posted so apologies in advance.
Anyways, simply trying to open a DICOM series with mrview causes this failure. The following is the -debug output.
mrview: [DEBUG] No config file found at "/etc/mrtrix.conf"
mrview: [DEBUG] No config file found at "~/.mrtrix.conf"
mrview: [INFO] GL renderer: GeForce GTX 285/PCIe/SSE2
mrview: [INFO] GL version: 3.3.0 NVIDIA 340.104
mrview: [INFO] GL vendor: NVIDIA Corporation
mrview: [DEBUG] loading font into OpenGL texture...
mrview: [DEBUG] compiling OpenGL vertex shader:
#version 330 core
layout(location = 0) in vec2 pos;
layout(location = 1) in vec2 font_pos;
uniform float scale_x;
uniform float scale_y;
out vec2 tex_coord;
void main () {
gl_Position = vec4 (pos[0]*scale_x-1.0, pos[1]*scale_y-1.0, 0.0, 1.0);
tex_coord = font_pos;
}
mrview: [DEBUG] compiling OpenGL fragment shader:
#version 330 core
in vec2 tex_coord;
uniform sampler2D sampler;
uniform float red, green, blue;
out vec4 color;
void main () {
color.ra = texture (sampler, tex_coord).rg;
color.rgb = color.r * vec3 (red, green, blue);
}
mrview: [DEBUG] font loaded
mrview: [INFO] opening image "~/Ser5"...
mrview: [DEBUG] memory-mapping file "~/Ser5/E7037S5I418.MR.dcm"...
mrview: [DEBUG] file "~/Ser5/E7037S5I418.MR.dcm" mapped at 0x7f1029403000, size 145404 (read-only)
mrview: [INFO] initialising DICOM dictionary
mrview: [SYSTEM FATAL CODE: SIGSEGV (11)] Segmentation fault: Invalid memory access
I had zero problems configuring or installing the software, however a few warnings did appear during CC stages, but no errors. I’m not sure what I could be doing wrong since it’s just a simple file open.
OK, that’s not cool… This looks similar to issues we had earlier, due to incompatibilities with Eigen 3.3. But these have been resolved for some time, and should no longer happen with any recent version of MRtrix3. So let’s rule that out first: what does this report:
mrview -version
You’d need version 3.0_RC1 or later to ensure that’s not the issue. If you’re running an old version, try updating first, see if that fixes the issue:
git checkout master
git pull
./configure
./build
Otherwise, I suspect the crash happens in the image loading backend, so you’d see it with a simple
mrinfo data.mif
If that doesn’t crash, try
mrstats data.mif
If one of the above crashes, that would already give us a pretty good idea where the problem might be…
Say, this reminds me of something that I once thought of: would it be useful to have any command run with -debug also output the version automatically? It’s not the first time I see a user report a debug output, only to have to follow up with a version request.
mrview -version
== mrview 3.0_RC2-73-gf4d3e52c ==
64 bit release version, built Oct 30 2017, using Eigen 3.3.3
Author(s): J-Donald Tournier (jdtournier@gmail.com), Dave Raffelt (david.raffelt@florey.edu.au), Robert E. Smith (robert.smith@florey.edu.au), Rami Tabbara (rami.tabbara@florey.edu.au), Max Pietsch (maximilian.pietsch@kcl.ac.uk), Thijs Dhollander (thijs.dhollander@gmail.com)
Copyright (c) 2008-2017 the MRtrix3 contributors.
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, you can obtain one at http://mozilla.org/MPL/2.0/.
MRtrix is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
For more details, see http://www.mrtrix.org/.
As for the other two I don’t have a .mif file to open. I can open up a NIFTI file, but still I cannot import any DICOM series.
Maybe it’s worth noting that the same segmentation fault: invalid memory access appears if I try to run mrconvert on a DICOM series as well. That seems to be where the issue is located.
Ok, this is a recent version, and as I suspected, it looks like the issue lies within the image handling backend somewhere, since mrconvert also crashes out. Any chance you could send me the problematic dataset?
If you’re feeling adventurous, instructions for providing more comprehensive debugging information (which are probably the first steps that @jdtournier will be performing if provided with the data) are here.
Ok, there’s a bug in there somewhere. But it’s only triggered by your data, so there’s something about it that breaks our assumptions. We’d get more information about exactly where the problem occurs if you could type bt after that crash within thegdb session. But ultimately, I think I’ll need access to your data so I can reproduce and fix this…
