-s y doesn't work

[yuqian-liu]

-s y option doesn't work. How can we fix this?

./dcm2niix -s y test.DCM
Chris Rorden's dcm2niiX version v1.0.20201102 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 x86-64 (64-bit Linux)
Segmentation fault (core dumped)

Thank you

[neurolabusc]

I believe this is fixed in the development branch. You can test this by building your own copy:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix

[yuqian-liu]

Thank you for reply. This one still doesn't work.

[neurolabusc]

Fixed with latest commit to development branch. Please test and close this issue once you confirm this resolves your issue.

[yuqian-liu]

Still have the same issue.
Our command options are:
./dcm2niix -f test.01 -o /tmp/NIFTI -s y /tmp/DICOMM/test.DCM

Thank you

[baxpr]

I wonder if this is something about the specific dicom file. It worked ok for me with a different dicom. @yuqian-liu let's check a few different dicom files.

[baxpr]

... Ok, we checked a few and the seg fault is still happening with commit 25e314a when the -s y option is used.

[neurolabusc]

@yuqian-liu I can not replicate. Can you share an example image (send GoogleDrive/DropBox link to email listed in my avatar).

[baxpr]

@yuqian-liu @neurolabusc I have it handy, I will send

[baxpr]

uname for the server we are testing on:

Linux 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[neurolabusc]

Curious, the code leaked when compiled with gcc, but not with Clang. The latest commit should resolve this. By the way, the address sanitizer is a nice way to detect leaks with gcc or clang. So once I had a compiler that elicited the issue, I could run the following to detect the problem:

g++ -O1 -g -fsanitize=address -fno-omit-frame-pointer  -I.  main_console.cpp nii_foreign.cpp nii_dicom.cpp jpg_0XC3.cpp ujpeg.cpp nifti1_io_core.cpp nii_ortho.cpp nii_dicom_batch.cpp  -o dcm2niix -DmyDisableOpenJPEG
./dcm2niix -f test.01 -o /tmp/NIFTI -s y /tmp/DICOMM/test.DCM

[yuqian-liu]

Thank you The address sanitizer works.

When I run it I got:
usr/bin/ld: cannot find /usr/lib64/libasan.so.0.0.0
collect2: error: ld returned 1 exit status

Then I installed the module and make.

[yuqian-liu]

Btw, After installed the libasan.so.0.0.0 module, the makefile still won't generate a correct binary. I will have to use the command you provided to get the correct one.

[baxpr]

Confirmed - still getting the seg fault with 8725ec5.

[neurolabusc]

Difficult for me to provide advice, as both Clang and GCC produce no errors on my Mac and Linux systems with the images you provided. I note you are running an Linux kernel from June 2013. Have you ensured your compiler is up to date? Here was my Linux system:

Linux ryzen 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[baxpr]

Ok, thanks. Given this works:

g++ -O1 -g -fsanitize=address -fno-omit-frame-pointer

And this does not:

g++ -s -O3

Does that give you any hints? Anyway we do have a solution, @yuqian-liu has verified the first one gives a working binary.

...and sounds like it's time to look at our OS version too

[neurolabusc]

It looks like you are using gcc 5.5.0. I tested gcc 9.3.0 and Clang 12.0. You can always build different optimization levels (-O0= none, -O3 is faster). In theory, different optimization levels should all work the same, but once upon a time the higher levels were known to be a bit buggy (for this reason tools like AFNI only use -O2 to this day). I have not seen any issues myself in the last few years, but you are using a legacy compiler. The only impact of -s should only be to strip the symbol table and relocation information from the executable, which should only decrease the size of the executable. It sounds like your version of gcc has an issue with higher optimization levels. You could try increasing the optimization level until the software crashes, and then run the sanitizer to see if it gives you any insights, e.g.

g++ -O3 -g -fsanitize=address -foo-omit-frame-pointer

Alternatively, just run the -O1 version.

[baxpr]

Thanks much! I reckon we're properly sorted so @yuqian-liu can you close this again?

[baxpr]

@neurolabusc I am no longer able to replicate the problem with commit 25e314a. Looks like we had a system update:

Linux theta.vuiis.org 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

The new version (development branch) works fine too, for what that's worth.