Segmentation fault

[mcraig-ibme]

Describe the bug

Segmentation fault trying to convert certain DICOM files

To reproduce

dcm2niix -o nifti 53

where 53 contains DICOMs from a certain scan session (all the scans in this session are failing to convert)

I have opened the DICOM files in MicroDICOM and they display OK

Output log

Run in gdb on fresh source build generating the following log

(gdb) run
Starting program: /home/martin/code/thirdparty/dcm2niix/debug/bin/dcm2niix -o nifti 53
Chris Rorden's dcm2niiX version v1.0.20220720  GCC9.3.0 x86-64 (64-bit Linux)
Found 30 DICOM file(s)

Program received signal SIGSEGV, Segmentation fault.
0x000055555556aba4 in readCSAImageHeader (buff=0x7ffff76d9d4a "SV10\004\003\002\001e", lLength=11504,
    CSA=0x7fffffffacec, isVerbose=0, is3DAcq=false) at /home/martin/code/thirdparty/dcm2niix/console/nii_dicom.cpp:1424
1424                                    memcpy(&itemCSA, &buff[lPos], sizeof(itemCSA));
(gdb) bt
#0  0x000055555556aba4 in readCSAImageHeader (buff=0x7ffff76d9d4a "SV10\004\003\002\001e", lLength=11504,
    CSA=0x7fffffffacec, isVerbose=0, is3DAcq=false) at /home/martin/code/thirdparty/dcm2niix/console/nii_dicom.cpp:1424
#1  0x0000555555580fee in readDICOMx (
    fname=0x5555556a5520 "53/DICOM/1.2.826.0.1.3680043.9.3218.1.1.1797400.1074.1621000103887.2311.0.dcm",
    prefs=0x7fffffffbe44, dti4D=0x7ffff770b010) at /home/martin/code/thirdparty/dcm2niix/console/nii_dicom.cpp:6706
#2  0x00005555555cf13e in nii_loadDirCore (indir=0x7fffffffd1d0 "53", opts=0x7fffffffcd90)
    at /home/martin/code/thirdparty/dcm2niix/console/nii_dicom_batch.cpp:8159
#3  0x00005555555d0738 in nii_loadDir (opts=0x7fffffffcd90)
    at /home/martin/code/thirdparty/dcm2niix/console/nii_dicom_batch.cpp:8538
#4  0x0000555555566c35 in main (argc=4, argv=0x7fffffffdf78)
    at /home/martin/code/thirdparty/dcm2niix/console/main_console.cpp:604
(gdb)

Version

Current Github code

dcm2niiX version v1.0.20220720 GCC9.3.0 x86-64 (64-bit Linux)

Also tried using development branch code, same error and backtrace

[neurolabusc]

Sounds like your CSA header is corrupted, MicroDICOM does not read the CSA header. Can you send the troublesome image to my institutional email. The other options to troubleshoot are to use dcm2niix in ogorrheic (-v 2) mode.

I also find compiling with the address sanitizer helpful:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
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 ....

[mcraig-ibme]

Thanks for the quick reply. I've tried with the address sanitizer and get the following:

Found 30 DICOM file(s)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==16091==ERROR: AddressSanitizer: SEGV on unknown address 0x7f63b213150a (pc 0x55bc7177147e bp 0x7ffeb5ba4920 sp 0x7ffeb5ba4760 T0)
==16091==The signal is caused by a READ memory access.
    #0 0x55bc7177147d in readCSAImageHeader(unsigned char*, int, TCSAdata*, int, bool) /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
    #1 0x55bc7179e450 in readDICOMx /home/martin/code/thirdparty/dcm2niix/console/nii_dicom.cpp:6733
    #2 0x55bc71823c22 in nii_loadDirCore /home/martin/code/thirdparty/dcm2niix/console/nii_dicom_batch.cpp:8159
    #3 0x55bc7182674c in nii_loadDir /home/martin/code/thirdparty/dcm2niix/console/nii_dicom_batch.cpp:8538
    #4 0x55bc717635a5 in main /home/martin/code/thirdparty/dcm2niix/console/main_console.cpp:604
    #5 0x7f634f6360b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #6 0x55bc7176008d in _start (/home/martin/code/thirdparty/dcm2niix/console/dcm2niix+0x1a08d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 in readCSAImageHeader(unsigned char*, int, TCSAdata*, int, bool)
==16091==ABORTING

I also added -v 2 which gave the following additional output:

Found 30 DICOM file(s)
212
 0002,0001 2@156 OB
 0002,0002 26@166 UI  1.2.840.10008.5.1.4.1.1.4
 0002,0003 64@200 UI  1.2.826.0.1.3680043.9.3218.1.1.1797400.1074.1621000103887.2311.0
 0002,0010 22@272 UI  1.2.840.10008.1.2.4.70
 0002,0012 30@302 UI  1.2.826.0.1.2860002.1.2.10011
 0002,0016 16@340 AE  DCMPseudonymiser
 0008,0005 10@364 CS  ISO_IR 100
 0008,0008 30@382 CS  ORIGINAL_PRIMARY_M_NORM_DIS2D
 0008,0012 8@420 DA  21190221
 0008,0013 6@436 TM  000000
 0008,0016 26@450 UI  1.2.840.10008.5.1.4.1.1.4
 0008,0018 64@484 UI  1.2.826.0.1.3680043.9.3218.1.1.1797400.1074.1621000103887.2311.0
 0008,0020 8@556 DA  20210514
 0008,0021 8@572 DA  21190221
 0008,0022 8@588 DA  20210514
 0008,0023 8@604 DA  21190221
 0008,0030 6@620 TM  000000
 0008,0031 6@634 TM  000000
 0008,0032 14@648 TM  140310.345000
 0008,0033 6@670 TM  000000
 0008,0050 16@684 SH  Data anonymised
 0008,0060 2@708 CS  MR
 0008,0061 2@718 CS  MR
 0008,0070 8@728 LO  SIEMENS
 0008,0080 8@744 LO  site_664
 0008,0081 16@760 ST  Data anonymised
 0008,0090 20@784 PN  Data anonymised^^^^
 0008,1010 16@812 SH  Data anonymised
 0008,1030 10@836 LO  MRI Heart
 0008,103e 28@854 LO  t2w_haste_cor_kidneys+spleen
 0008,1040 16@890 LO  Data anonymised
 0008,1050 20@914 PN  Data anonymised^^^^
 0008,1090 6@942 LO  Prisma
 0008,1140 8@952 SQ
  fffe,e000 4@964 SQ
  0008,1150 26@976 UI  1.2.840.10008.5.1.4.1.1.4
  0008,1155 64@1010 UI  1.2.826.0.1.3680043.9.3218.1.1.1797400.1074.1621000103887.2295.0
 fffe,e00d 4@1078 NA
  fffe,e000 4@1086 NA
  0008,1150 26@1098 UI  1.2.840.10008.5.1.4.1.1.4
  0008,1155 64@1132 UI  1.2.826.0.1.3680043.9.3218.1.1.1797400.1074.1621000103887.2296.0
 fffe,e00d 4@1200 NA
  fffe,e000 4@1208 NA
  0008,1150 26@1220 UI  1.2.840.10008.5.1.4.1.1.4
  0008,1155 64@1254 UI  1.2.826.0.1.3680043.9.3218.1.1.1797400.1074.1621000103887.2297.0
 fffe,e00d 4@1322 NA
 fffe,e0dd 4@1330 NA
 0010,0010 12@1342 PN  CMO 013 015
 0010,0020 12@1362 LO  CMO 013 015
 0010,0021 16@1382 LO  Data anonymised
 0010,0030 8@1406 DA  19730101
 0010,0040 2@1422 CS  F
 0010,1000 16@1432 LO  Data anonymised
 0010,1002 8@1452 SQ
  fffe,e000 4@1464 SQ
  0010,0020 16@1476 LO  Data anonymised
  0010,0021 16@1500 LO  Data anonymised
  0010,0022 0@1524 CS
 fffe,e00d 4@1528 NA
  fffe,e000 4@1536 NA
  0010,0020 16@1548 LO  Data anonymised
  0010,0021 16@1572 LO  Data anonymised
  0010,0022 0@1596 CS
 fffe,e00d 4@1600 NA
 fffe,e0dd 4@1608 NA
 0010,1010 4@1620 AS  047Y
 0010,1020 4@1632 DS  1.59
 0010,1030 2@1644 DS  81
 0012,0062 4@1654 CS  YES
 0012,0064 8@1662 SQ
  fffe,e000 4@1674 SQ
  0008,0100 6@1686 SH  113100
  0008,0102 4@1700 SH  DCM
  0008,0104 42@1712 LO  Basic Application Confidentiality Profile
 fffe,e00d 4@1758 NA
  fffe,e000 4@1766 NA
  0008,0100 6@1778 SH  210004
  0008,0102 6@1792 SH  99PMP
  0008,0104 22@1806 LO  Remove all descriptors
 fffe,e00d 4@1832 NA
  fffe,e000 4@1840 NA
  0008,0100 6@1852 SH  210001
  0008,0102 6@1866 SH  99PMP
  0008,0104 10@1880 LO  Remap UIDs
 fffe,e00d 4@1894 NA
  fffe,e000 4@1902 NA
  0008,0100 6@1914 SH  113107
  0008,0102 4@1928 SH  DCM
  0008,0104 62@1940 LO  Retain Longitudinal Temporal Information Modified Dates Option
 fffe,e00d 4@2006 NA
 fffe,e0dd 4@2014 NA
 0018,0015 6@2026 CS  KIDNEY
 0018,0020 2@2040 CS  SE
 0018,0021 10@2050 CS  SK_SP_OSP
 0018,0022 8@2068 CS  PFP_SFS
 0018,0023 2@2084 CS  2D
 0018,0024 10@2094 SH  _h2d1rr256
 0018,0025 2@2112 CS  N
 0018,0050 2@2122 DS  5
 0018,0080 4@2132 DS  438
 0018,0081 2@2144 DS  61
 0018,0083 2@2154 DS  1
 0018,0084 10@2164 DS  123.256306
 0018,0085 2@2182 SH  1H
 0018,0086 2@2192 IS  1
 0018,0087 2@2202 DS  3
 0018,0088 2@2212 DS  5
 0018,0089 4@2222 IS  238
 0018,0091 2@2234 IS  80
 0018,0093 4@2244 DS  100
 0018,0094 4@2256 DS  100
 0018,0095 4@2268 DS  780
 0018,1000 8@2280 LO  SN000000
 0018,1020 12@2296 LO  syngo MR E11
 0018,1030 28@2316 LO  t2w_haste_cor_kidneys+spleen
 0018,1251 4@2352 SH  Body
 0018,1310 8@2364 US 256
 0018,1312 4@2380 CS  COL
 0018,1314 4@2392 DS  105
 0018,131

I've asked the data owner if I can have permission to share a DICOM file from this session - will get back to you if that's possible.

[neurolabusc]

The output of -v 2 suggests the use of a crude anonymization method that simply fills DICOM tags with Data anonymised^^^^.... This method will clearly corrupt binary fields like the CSA header. An anonymization tool should remove the CSA header (at the cost of removing sequence details such as mosaic information) or preserve it.

dcm2niix should work if you can get DICOM files where the CSA header is not corrupted.

[mcraig-ibme]

Ok, I will go back to the team that acquired the data and find out how they have anonymised these sessions - it may be a particular site doing something odd. I have also sent you an example DICOM file if that's helpful in confirming this.

Thanks for the help

[hanayik]

Ok, I will go back to the team that acquired the data and find out how they have anonymised these sessions - it may be a particular site doing something odd. I have also sent you an example DICOM file if that's helpful in confirming this.

Thanks for the help

hi @mcraig-ibme, just wanted to chime in and say that I have also experienced errors like this before due to clinical data being aggressively anonymized before sharing with us. it might take some negotiating with the team that is sharing the data to get the anonymization just right.

[neurolabusc]

@mcraig-ibme thanks for sending a sample image. The binary data of the CSA header has been corrupted. Each tag of this header should be precisely 192 bytes, but with your dataset all of the fields are a variable amount longer than 192. Using a hex editor you can see that every occurrence of 0xCD has been replaced 0xC38D. Perhaps some tool assumes these are strings and trying to convert ASCII acutes to Unicode characters.

[mcraig-ibme]

Sounds plausible. We have requested a repeat send of this data set and will try to debug from there.

[neurolabusc]

I have tried to make dcm2niix a bit more resilient for reading CSA tags. It will abort reading a CSA header if the n_tags exceeds 128. I assume the nipy documentation is correct. Since this is a proprietary Siemens format, it is theoretically possible that some valid Siemens images violate this assumption. Any images which exceed the limit should generate an error message that directs users to this issue.

I am closing this issue as it reflects a corrupted DICOM file rather than a limitation with dcm2niix.

[captainnova]

We were getting spurious Error: 144 n_tags CSA Image Header corrupted (0029,1010) see issue 633. messages for DICOM with 101 CSA tags and a tag that has n_items 144 (but somewhat fewer items). Everything else seemed fine, but the message was triggering one of our bad DICOM alarms.

https://nipy.org/nibabel/dicom/siemens_csa.html suggests that the number of CSA tags should be between 1 and 128, but places no limit on the number of items a CSA tag may have, other than that the tag should fit inside the overall length of the CSA buffer. Unfortunately f7f376a checked the number of items per CSA tag instead of the number of CSA tags. PR coming shortly.

[captainnova]

PR coming shortly.

github automatically added d53a237 to PR #814 , probably because I did not make a new branch for this issue.

[neurolabusc]

PR merged, closing issue.