dwibiascorrect ants (mrconvert) error - out of storage space?

1

Hi all,

I’m new to MRtrix, but I’ve been attempting to figure out for a few weeks now why I am consistently receiving the following error when running the following command. (Note: Part of the path names are hidden for general data anonymity.)

Command:

dwibiascorrect ants ${subj}_dwi_peboth_eddy.nii.gz $biascorr_dir/${subj}_dwi_biascorr.nii.gz

Error:

dwibiascorrect: 
dwibiascorrect: Note that this script makes use of commands / algorithms that have relevant articles for citation; INCLUDING FROM EXTERNAL SOFTWARE PACKAGES. Please consult the help page (-help option) for more information.
dwibiascorrect: 
dwibiascorrect: Generated scratch directory: /mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/dwibiascorrect-tmp-LMXBDA/
Command:  mrconvert /mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/(subj)_dwi_peboth_eddy.nii.gz /mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/dwibiascorrect-tmp-LMXBDA/in.mif

dwibiascorrect: [ERROR] mrconvert /mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/(subj)_dwi_peboth_eddy.nii.gz /mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/dwibiascorrect-tmp-LMXBDA/in.mif (dwibiascorrect:50)
dwibiascorrect: [ERROR] Information from failed command:
dwibiascorrect:
                mrconvert: uncompressing image "/mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/(subj)_dwi_peboth_eddy.nii.gz"... [==================================================]
                mrconvert: copying from "/mnt/(drive)...(subj)_dwi_peboth_eddy.nii.gz" to "/mnt/(drive)...ascorrect-tmp-LMXBDA/in.mif"... [==
                mrconvert: [SYSTEM FATAL CODE: SIGBUS (7)] Bus error: Accessing invalid address (out of storage space?)
dwibiascorrect:
dwibiascorrect: [ERROR] For debugging, inspect contents of scratch directory: /mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/dwibiascorrect-tmp-LMXBDA/
dwibiascorrect: Scratch directory retained; location: /mnt/(drive)/(study)/(subj)/(subj)_diffusion_processed_old/preproc/eddy/dwibiascorrect-tmp-LMXBDA/

I saw previous forums (Out of storage space?, dwi2response bus error, and Unix /tmp becomes full) that are similar and a little on the older side but have not solved my issue.

On the mounted drive for which the tmp file is created, there is 2.5 TB of space available. In the tmp file, there are 4 txt files created in addition to the single in.mif file. I think there is something with the in.mif file where the issue is arising because I think this is one of the temporary files intended to be removed in the process.

I have attempted to clear the tmp folder, checked the storage space for both the tmp and eddy folders (which the tmp is only taking approximately 1.3 GB of space), as well as the drive as a whole, and ensured that the (subj)_dwi_peboth_eddy.nii.gz file is not corrupted.

Is there anything I can do to overcome this issue so that I can run the next -fslgrad and -bias commands and the rest of my script commands?

Thank you!

2

Hi @Stuy,

I have to admit, the SIGBUS signal is one that I’ve always struggled to understand… It’s one of those things that sometimes happens to commands on Linux systems, but I’ve never fully understood what the cause is exactly. From the internet, I can see various descriptions. This is from StackOverflow:

POSIX describes SIGBUS as:

Access to an undefined portion of a memory object.

The mmap spec says that:

References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal.

These are fairly cryptic descriptions, and don’t really explain the root cause. In the past, we’ve tended to see this error pop up when running out of storage space – which makes sense given that we do often use mmap to write the output data (I could try to explain why that is, but it requires a deep dive into the way memory management in performed on modern operating systems – let me know if you want me to go into it…).

But that doesn’t mean out of storage issues are the only way you can get a SIGBUS fault. Given the fact that your data are held on an external drive (at least, that’s what it looks like), I’d be looking very closely at the particular interconnect being used (USB? eSATA?) and the filesystem on the drive (FAT32? NTFS? ext3/4, exFAT…?). Some combinations of these may not be very stable.

One way to potentially get around this issue is to request the scratch folder be created somewhere other than on that external drive – hopefully some much quicker internal SSD storage. The troublesome command is a Python script, and these typically create a temporary ‘scratch’ folder to hold their temporary outputs. This folder is typically created in the same folder as the output, which in your case is clearly the external drive. You can use the -scratch option to specify a different location (e.g. -scratch ~/tmp-dwibiascorrect or something…). That might be sufficient to get things working again…

All the best,
Donald.