Yes, I would definitely suspect a memory issue in this instance, as previously experienced here and here. The clue is in the output provided after this line:
dwipreproc: Output of failed command:
It subsequently gives details of mrinfo not receiving the piped image it expects, but it’s mrconvert that is genuinely failing, and that command is not providing any terminal output at all.
Click here for the technical details of what's going on if you're interested
The issue is that it’s a very low-level system operation that goes awry. The memory-mapped output file gets truncated by the system without the memory-mapping code being made aware of it. When the code subsequently tries to access beyond the actual memory-mapped file size, it generates a bus error signal, which calls terminate().
When running a binary command directly, this will generate an error at the command-line such as: “Bus Error (core dumped)”; which is useful but maybe not verbose enough. However by default glibc writes this message to the current tty terminal rather than stderr. When executed within one of the Python scripts using subprocess, this message is lost.
Theoretically, setting the environment variable LIBC_FATAL_STDERR_ is supposed to instruct the signal handler to instead write the error to stderr; but in my experience this didn’t work.
Therefore, the actual solution is to register our own signal handlers that will be called in the event of a fatal system signal. Apart from customising the error messages, and making sure that they are written to stderr such that they can be piped appropriately, we can also perform limited cleanup in the event of catastrophic command failure: for instance, deleting any temporary image files used in piping.
Once we have confirmed and merged in the code changes here, both the MRtrix3 binaries and scripts should give more meaningful error messages when such a system error is encountered. Note however that this will require re-running the configure script to activate the changes, and is not guaranteed to be supported on all systems.
We are also considering modifying the Python scripts to create the temporary working directory in the current working directory by default, rather than using /tmp/ by default, in the hope that such memory issues are encountered less frequently. It will still be possible to set the temporary directory location manually using the -tempdir option if you know you have enough space in e.g. /tmp, and we’ll probably add a config file entry to control this behaviour as well.
Cheers
Rob