dicom_hdr and dicom_hinfo crashing with long filenames

AFNI Message Board
1

Dear Friends in AFNI,

I hope all is well.

dicom_hdr and dicom_hinfo are crashing with the below error when provided with long dicom filenames (~255 chars).

I thought the problem was in THD_zzprintf but I was wrong. Not sure what is causing this.

Cheers,
Z

Error message:
zsh: illegal hardware instruction dicom_hdr

2

Hey Z,

Is that with a long path or just a long /-less name?

A long path+name seems to work for me. A long directory-less name actually fails at the shell, with the error: File name too long

I cannot use 'touch or ‘mv’ for example, to create such a file.

  • rick
3

Hi Rick,

Good points but no cigar, the below has a script to reproduce the problem. It assumes you have AFNI_demo/CD under your home directory (where else would it be?).

My afni version is: Precompiled binary macos_10.12_local: Oct 1 2022 (Version AFNI_22.2.12 ‘Marcus Aurelius’)

Thanks!
Ziad

#!/bin/sh
crazypath=${PWD}/tmp/Volumes/ns2/MyFavoriteThings88/healer/transfer/BC_transfers/Minds_expanded/77566465JIM8008_CAT_DOG_TT_00001224.zip.exp/77566465JIM8008_CAT_DOG_TT_00001224/S38-SU98272B/SU98272003/Week_52_Mea_DOG/CAT/00001224/Catenation_Adjusted_Regression/00001224/

mkdir -p ${crazypath}
cp ~/AFNI_demo/CD/AFNI_data6/DICOM_T1/I1000000 ${crazypath}

echo “>>> This works :)”
cd ${crazypath}
dicom_hinfo -sepstr , -tag 0008,0022 0008,0031 0008,0032 0018,1242 I1000000

echo “>>> This doesn’t :(”
dicom_hinfo -sepstr , -tag 0008,0022 0008,0031 0008,0032 0018,1242 ${crazypath}/I1000000

4

Hmmm, the plot thickens. Those commands work for me.
And I cannot test on my home mac right now. Complications…

Does this work for you?

head ${crazypath}/I1000000

  • rick
5

I am able to duplicate this - sort of. I don’t get an error, but the long path doesn’t return anything at all. The long path doesn’t work under Rosetta emulation mode with our MacOS binaries, but both short and long paths work on binaries built from source on an M1 system. Are there any cigars for M1/M2 Apple system here?

Additional info - I do get an “Illegal instruction” error if run this with “sh” or “bash” instead of “zsh”, the default shell on the Mac now.

ziadbug.sh: line 12: 47228 Illegal instruction: 4 dicom_hinfo -sepstr , -tag 0008,0022 0008,0031 0008,0032 0018,1242 ${crazypath}/I1000000

6

Hi Rick, Daniel,

Glad I managed to provide some intrigue.
The head command works fine.

Cheers,
Z

7

Are you running this on an M1 or M2 Mac?
Are you doing this in a Rosetta Terminal or the standard Terminal?
Which shell in the terminal? As an sh script within that shell?

8

Hi Daniel,

This is happening on a mac pro 2019, Intel Xeon W. The command is failing in zsh and I am using iTterm2 , but the dicom_hinfo command also fails from Terminal, whether using zsh, sh, or tcsh.

Cheers,
Z

9

I see an “illegal instruction” on an Intel Mac too, but it works with binaries built on the same machine. Okay, one more question (at least) - what version of OS are you using?

Can you try this copy of my 10.15 binaries and see if this works for you?

https://afni.nimh.nih.gov/pub/dist/tgz/macos_10.15_local_gcc_clang.tgz

10

Hi Daniel,

I am running Monterey (12.6.3).

macos_10.15_local_gcc_clang/dicom_hinfo works fine!

All the best,
Ziad

11

Hi Daniel,

Any thoughts on this problem?

All the best,
Ziad

12

Hi Z.
My guess is to why this happens is there is some optimization that doesn’t translate across MacOS versions. That’s based on similar kinds of issues with illegal instructions on differing versions. We could compile these particular programs with no optimization or… we could compile for the more current MacOS. More recent OS’s can also require code signing which we still don’t do. One good solution then is to make scripts that do the building for you. That should be available soon. Hopefully. In the meantime, would the binaries for those two programs be okay as is? Can you build AFNI for your own system?

13

Hi Daniel,

Thanks for the reply. I would love to be able to build regularly but I often run into glitches that I don’t have time to resolve. I need the whole package to run seamlessly, including dependencies on R_io.so.
If you have new tools to automate the build I would be happy to test them out.
In the meanwhile, I grabbed the dicom_ programs from the version that worked and that seems fine.

All the best,
Ziad