-
-
Notifications
You must be signed in to change notification settings - Fork 663
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
BUG: Allow nifti load to fail #3529
BUG: Allow nifti load to fail #3529
Conversation
35f2d5b
to
7d14b45
Compare
When attempting to write to an invalid file location, ensure that an itk::ExceptionObject is thrown.
When attempting to write a nifti file to an invalid location (for example, C:\Windows\something.nii) then no file is created there yet no error is reported. The issue is that the error is swallowed in both niftilib and nifti2 (just "reported" with LNI_FERR macro, which does not throw an exception or reports the error to ITK in any other way): Resolves: InsightSoftwareConsortium#1958
Ensure that caught exceptions are converted to itk::Exception objects.
9bcfb58
to
5e6824f
Compare
When re-using the HDF IO object, all internal state variables should be reset to the initial state as if the object had been constructed anew. Previously, the WriteImageInformation function would set the value m_ImageInformationWritten to true, and it would never again be set to false.
The HDF5ImageIO objects are single use for writing. After the initial use, the WriteImageInformation function is short circuited, and can not be reset for writing a second image. This bug was exposed while fixing a problem with the not throwing an exception when attempting to write to a path that does not exist. This temporary work around in the test framework allows fixing the initial problem without requiring fixing the HDF5ImageIO re-use issues. NOTE: Resetting the HDF5ImageIO object at the end of writing fixes the re-use problem for non-streaming case, but that causes the streaming tests to fail.
5e6824f
to
f244a81
Compare
@dzenanz I tried to use ITK macros for the excepion handling in the tests, but did not have time to figure out why the builds failed due to missing header files. |
Not sure whether this caused the memory leaks that appeared today: The ones for |
Fix proposed in PR #3545. |
The MINC-related Valgrind defects persist: Detail Looks like the changes to the The most prior recent changes to MINC classes did not incur Valgrind defects: Have not investigated further. |
The problems are in MINC IO. The changes in this PR just made the problems visible. There are several leaks if MINC IO exits with exception, it doesn't delete many allocations. The easiest one is e.g. at line 1166 That
But there are many more, unfortunately. I have done trivial test, without using itkIOTestHelper.h, just read MHA and write MNC to wrong path, the leaks are there. If the path is correct -- there are no problems, so this PR has done a good job and discovered ancient problems, IMHO. |
MINC IO often did not free allocations before thowing an exception, detected by InsightSoftwareConsortium#3529
This seems to work |
MINC IO often did not free allocations before thowing an exception, detected by InsightSoftwareConsortium#3529
MINC IO often did not free allocations before throwing an exception, detected by InsightSoftwareConsortium#3529
MINC IO doesn't always free allocations before throwing an exception, detected by InsightSoftwareConsortium#3529.
MINC IO doesn't always free allocations before throwing an exception, detected by InsightSoftwareConsortium#3529.
MINC IO doesn't always free allocations before throwing an exception, detected by #3529.
MINC IO doesn't always free allocations before throwing an exception, detected by InsightSoftwareConsortium#3529.
MINC IO doesn't always free allocations before throwing an exception, detected by InsightSoftwareConsortium#3529.
MINC IO doesn't always free allocations before throwing an exception, detected by InsightSoftwareConsortium#3529.
MINC IO doesn't always free allocations before throwing an exception, detected by InsightSoftwareConsortium#3529.
Ensure that attempts to write to invalid file paths causes error to be reported. Ref #1958.
PR Checklist