Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix 32bits dicom read crash #4522

Merged

Conversation

lassoan
Copy link
Contributor

@lassoan lassoan commented Mar 17, 2024

Fix crash in ITK DICOM reader when attempting to read an unusual but valid DICOM file, which has 32 bits allocated.
Fixes the error reported at https://discourse.slicer.org/t/slicer-crashes-while-trying-to-load-dicom-files/34931/3

PR Checklist

  • No API changes were made (or the changes have been approved)
  • No major design changes were made (or the changes have been approved)
  • Added test (or behavior not changed)
  • Updated API documentation (or API not changed)
  • Added license to new files (if any)
  • Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
  • Added ITK examples for all new major features (if any)

Refer to the ITK Software Guide for
further development details if necessary.

@github-actions github-actions bot added area:IO Issues affecting the IO module area:ThirdParty Issues affecting the ThirdParty module labels Mar 17, 2024
Comment on lines -42 to +56
static bool
readPreambleDicom(std::ifstream & file)
bool
isPreambleDicom(std::ifstream & file)
{
file.seekg(0, std::ios::beg);
std::vector<char> buffer(DCM_PreambleLen + DCM_MagicLen);
file.read(&buffer[0], buffer.size());
if (!file)
{
return false;
}
const char * magicReadFromFile = &buffer[DCM_PreambleLen];
return strncmp(magicReadFromFile, DCM_Magic, DCM_MagicLen) == 0;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, my first commit is just a style improvement (and a little performance improvement) over #4501. There is no functional difference.

#4501 did not fix the issue because the application first tries to read the DICOM image using GDCM and if it fails then it uses DCMTK. However, GDCM did not return with an error but it crashed the application, so the application did not have a chance to use DCMTK.

Copy link
Member

@thewtex thewtex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice @lassoan !

Could you please:

  • split the GDCM change into a patch and PR against malaterre/GDCM for the release branch
  • Add a test here with the file reported on the Slicer Discourse for both ITKIOGDCM and ITKIODCMTK to ensure we do not crash

?

@lassoan
Copy link
Contributor Author

lassoan commented Mar 18, 2024

  • split the GDCM change into a patch and PR against malaterre/GDCM for the release branch

malaterre/GDCM: I got a message when I committed that I would need to send something to sourceforge. The link did not work, so I hoped that I didn't need to deal with it. It seems that GDCM is on github now - https://github.com/malaterre/GDCM - do you mean I should send a pull request there?

  • Add a test here with the file reported on the Slicer Discourse for both ITKIOGDCM and ITKIODCMTK to ensure we do not crash

I've asked for permission for using a slice of the data set as test data: https://discourse.slicer.org/t/slicer-crashes-while-trying-to-load-dicom-files/34931/5

@thewtex
Copy link
Member

thewtex commented Mar 18, 2024

https://github.com/malaterre/GDCM - do you mean I should send a pull request there?

Yes, please. We integrate patches from there into ITK if accepted.

I've asked for permission for using a slice of the data set as test data: https://discourse.slicer.org/t/slicer-crashes-while-trying-to-load-dicom-files/34931/5

Most excellent.

@lassoan
Copy link
Contributor Author

lassoan commented Mar 19, 2024

Submitted a PR to GDCM:

malaterre/GDCM#168

@lassoan lassoan force-pushed the fix-32bits-dicom-read-crash branch from e3058e6 to 55f2f0c Compare March 19, 2024 03:12
@github-actions github-actions bot added type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots type:Testing Ensure that the purpose of a class is met/the results on a wide set of test cases are correct labels Mar 19, 2024
@thewtex
Copy link
Member

thewtex commented Mar 20, 2024

Thank you @lassoan !

LGTM.

Path to integration:

  1. Merge GDCM Secondary Capture spatial metadata #4521
  2. I will create another PR that integrates BUG: Fix GDCM crash when reading DICOM image malaterre/GDCM#168 via our subtree merge process.
  3. Rebase this PR

@lassoan
Copy link
Contributor Author

lassoan commented Mar 21, 2024

Thank you! Let me know if you need any help from me.

@lassoan
Copy link
Contributor Author

lassoan commented Mar 22, 2024

The GDCM pull request has been merged.

@hjmjohnson
Copy link
Member

@lassoan Thanks!

@thewtex
Copy link
Member

thewtex commented Mar 25, 2024

Both the GDCM patch for this branch and the GDCM patch for #4521 have been integrated into GDCM, and these are integrated in #4521 -> after #4521 has been merged, this branch can be rebased and merged.

Do not test for no-preamble DICOM file format if standard preamble format is found.
Use DCMTK constants (instead of hardcoding the preamble size, magic word, etc.).
Remove unnecessary "static" keyword from function in anonymous namespace.
Simplified debug message of a DICOM file without preamble.
GDCM used to crash the application when it encountered a DICOM image that had 32 bits stored.
This new test checks that GDCM does not crash anymore for such images.
@thewtex thewtex force-pushed the fix-32bits-dicom-read-crash branch from 55f2f0c to 7e350ef Compare March 26, 2024 14:25
@github-actions github-actions bot removed the area:ThirdParty Issues affecting the ThirdParty module label Mar 26, 2024
@thewtex
Copy link
Member

thewtex commented Mar 26, 2024

Dropped the GDCM patch (integrated via malaterre/GDCM#168 and #4521 ) and rebased.

@thewtex thewtex merged commit 5f3adbd into InsightSoftwareConsortium:master Mar 26, 2024
12 checks passed
@lassoan lassoan deleted the fix-32bits-dicom-read-crash branch March 27, 2024 01:45
@lassoan
Copy link
Contributor Author

lassoan commented Mar 27, 2024

Thank you @thewtex!

@dzenanz
Copy link
Member

dzenanz commented Mar 27, 2024

From the dashboard:

/Users/builder/external/ITK/Modules/IO/GDCM/src/itkGDCMImageIO.cxx:191:3: error: invalid use of 'this' outside of a non-static member function
  itkDebugMacro(<< "No DICOM magic number found, but the file appears to be DICOM without a preamble.");
  ^

Probably use itkWarningMacro instead of itkDebugMacro?

@SimonRit
Copy link

It believe it will be the same problem for itkWarningMacro (use of this->GetNameOfClass()). I was about to submit the following patch:

-  itkDebugMacro(<< "No DICOM magic number found, but the file appears to be DICOM without a preamble.");
+#ifndef NDEBUG
+  itkGenericOutputMacro("No DICOM magic number found, but the file appears to be DICOM without a preamble.");
+#endif

which compiles, what do you think?

@dzenanz
Copy link
Member

dzenanz commented Mar 27, 2024

I would prefer to remove the debug statement entirely.

@SimonRit
Copy link

Sounds good to me, that should also compile!

@lassoan
Copy link
Contributor Author

lassoan commented Mar 27, 2024

Sorry, all testing was done in release mode, probably that's why this error was not caught.

The log message was there before, I just switched to using a macro. Since detection of a DICOM file without a preamble requires some heuristics, so when investigating why a file is detected/not detected as DICOM it might be useful to know the result of the heuristic check. But it should not be logged every time when a DICOM file without a preamble is encountered.

Has somebody started to work on a new pull request or I should do it?

@dzenanz
Copy link
Member

dzenanz commented Mar 27, 2024

I have not started any work. I am giving other people a chance to fix this 😄

@SimonRit
Copy link

Nope, I haven't done more than testing the patch I suggested. Go ahead!

@seanm
Copy link
Contributor

seanm commented Mar 28, 2024

@lassoan do you have a fix in the works?

@dzenanz
Copy link
Member

dzenanz commented Mar 28, 2024

@seanm There is #4544.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:IO Issues affecting the IO module type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots type:Testing Ensure that the purpose of a class is met/the results on a wide set of test cases are correct
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants