What you’ve printed subsequent to that is the Python code that is responsible for detecting the endian-ness of your system. But given that configure is a script that executes, it tells me nothing about the result of that test when run on your system; that’s what the contents of the file config tell me.
I tried to run the advanced debugging but ran over some problems: When running the ./configure -debug -assert, I ran over the following error message:
“MRtrix3 was unable to compile a test program involving Eigen3”.
I then adjusted the EIGEN_CFLAGS environment as suggested by the error message. After running the ./configure again, there was a similar problem with the qt5 ("MRtrix3 was unable to locate the Qt meta-object compiler ‘moc’), and again I adjusted those paths as suggested. After that, I tried running the ./configure a third time, this time receiving:
ERROR: qmake returned with error:
Project ERROR: Could not resolve SDK Path for ‘macosx10.12’
ERROR: unexpected exception!
I then went on to check the configure.log file, but couldn’t identifiy the error. Can you help?
For some reason, I’ve been able to run mrview without problems using the “Start debugging” option in the Qt Creator GUI. I’ve tried running the same binary from bash with and without gdb and I can’t view the meshes in those cases.
Also, running in debug mode from Qt Creator allows me to load streamtubes.
I’m stumped. I just checked this on my Arch Linux setup, and my Win10 MSYS2 laptop, everything works as expected. But given the issues raised in this thread, there’s a suggestion of a funny interaction with Qt5 that might be causing issues. Maybe you could try removing the Qt5 development packages, installing the Qt4 equivalent packages, then running ./configure and ./build again, and see if that fixes the issue?
Otherwise, I’ve no idea how the same binary executed within the Qt debugger could possibly behave differently outside of it. But it does suggest a potential memory issue, I’ll have a look into that next week if I find the time…
I’m not sure a debug build is necessarily going to help if the software doesn’t crash outright. I wouldn’t bother, just keep using the version you’ve already installed (through homebrew, presumably?). It seems there are issues somewhere in the OpenGL handling, given that similar issues are being reported on other systems. This is not something you’ll be able to fix or even investigate very easily. Unfortunately I’m not in a position to replicate the issue, but I’ll give it a shot next week if I find the time…
After some debugging, we’ve reached the conclusion that it seems to be a problem with the LC_NUMERIC locale. We have our systems configured in Spanish, where “,” is the decimal separator. This can be causing the sscanf (data.c_str(), “%f %f %f %f”, &values[0], &values[1], &values[2], &values[3]);
reads wrong positions.
If we include something like this
import <locale.h>
…
setlocale(LC_NUMERIC, “C”);
in the MeshMulti::load function, meshes work fine.
I’m not sure if that can be the related to what is happening with streamtubes.
Alberto.
EDIT: “locale.h” was wrong. It should be <locale.h> because the previous had a compilation error.
I have installed mrtirx through macports instead of homebrew. I guess that makes no difference? Unfortunately, Alberto’s suggestion to change the MeshMulti::load function doesn’t do the trick for me. Would you need the data I’ve been using to replicate the issue?
Wow, great work! That can’t have been easy to track down…
This sounds similar to this issue that @bjeurissen encountered a while back. The added problem there was that this was internal to Qt, which meant we couldn’t modify the code – there was nothing we could do other than modify the locale, in pretty much the same way as you suggest.
However, in this instance, we do have control of the relevant code. @rsmith, I suggest we change the problematic line from what it is now:
Not really, but it will affect the exact procedure and the specific flags that might need to be set in the configure call. So it helps to know if we’re trying to help you to compile a debug build. You should be able to use the exact same steps as you must have used to compile your original installation, but with -assert -debug at the end of the ./configure line – everything else should be the same…
I think we’ll need to take a look at the data to get to the bottom of this. But before we do, it might be worth looking into whether you might not have the reverse issue: maybe the numbers are written in the file using the comma as the decimal separator, and your locale is set to use a dot? Can you look at the file in a text editor and see how the numbers are stored? It should be just text…
OK, so here are the first few lines of my .obj file:
# mrtrix_version: 3.0_RC2-37-gb4bca32f
o none
o 1
v -31.120390560477745 -56.278932370245329 -16.580981446196731 1.0
v -31.620390579104196 -55.778932373970619 -16.580981401260416 1.0
v -31.120390597730648 -55.778932400047651 -17.080981490667384 1.0
OK, that doesn’t seem to be the issue. Feel free to send me the problematic file, by email or any other means: jdtournier@gmail.com, I’ll take a look when I have a minute.
For me, when i do label2mesh and mesh filter. None of the files produces any node.
I have tried to build mrtrix with various versions of Qt, including two qt4 and two qt5 versions with no difference.
I even did start debugging with Qt Creator GUI, but nothing.
Here is my openGL information and picture that i get.
@martahedl: Could you try locally modifying the code according to @jdtournier’s suggestion? If this is a more general issue around text-string conversions in different locales, it might require a decent block of changes to MRtrix3, which will take a bit of work, so I’d like to know beforehand whether or not such a modification actually fixes the issue. @david142: You could try the same modification if you’d like.
Also, if anyone encountering the issue could provide the output of the locale command, that might help to determine whether or not we’re going down the right rabbit-hole.
That’s strange. LC_NUMERIC for de_DE uses “,” as decimal separator (I’m not sure in the case of hr_HR).
In case it helps, the steps I made for solving the issue in three different Ubuntu/Debian machines were the following:
First, change the code in MeshMulti::load (src/surface/mesh_multi.cpp) replacing the line sscanf (data.c_str(), “%f %f %f %f”, &values[0], &values[1], &values[2], &values[3]);
with @jdtournier’s sugggestion:
auto list = split (data);
for (int n = 0; n < 4; ++n)
values[n] = to(list[n]);
Finally, recompile mrview with ./build bin/mrview
Also maybe you can try to change LC_NUMERIC to en_US.utf8 in your system. I tried that and also does the trick for me.