ImageFileWriter crashes when writing MHD file to long absolute path

Hi all,

I have encountered a problem with the itk::ImageFileWriter when writing mhd files.

When the absolute path exceeds 263 characters, the program crashes with a segfault in the UnRegister method of the itkSmartPointer.

The code (adapted from the ITK Example ImageFileWriter) to reproduce this error is here:

#include "itkImage.h"
#include "itkImageFileWriter.h"

#include <iostream>
#include <string>

int main( int argc, char* argv[] )
{
  std::string absolutePathDoCrash = "/home/abcdef/Desktop/delete/itk/ImageFileWriter/build-verylongFOlderNamexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-Desktop_Qt_5_12_0_Clang_64bit-Debug/abcdefghijklmnopqrstuvwxyzABCDEFGHI.mhd";
  std::string absolutePathNoCrash = "/home/abcdef/Desktop/delete/itk/ImageFileWriter/build-verylongFOlderNamexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-Desktop_Qt_5_12_0_Clang_64bit-Debug/abcdefghijklmnopqrstuvwxyzABCDEFGH.mhd";
  std::string absolutePathNoComme = "/home/abcdef/Desktop/delete/itk/ImageFileWriter/build-verylongFOlderNamexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-Desktop_Qt_5_12_0_Clang_64bit-Debug/abcdefghijklmnopqrstuvwxyz.mhd";

  typedef unsigned char     PixelType;
  const     unsigned int    Dimension = 2;
  typedef itk::Image< PixelType, Dimension >  ImageType;

  ImageType::RegionType region;
  ImageType::IndexType start;
  start[0] = 0;
  start[1] = 0;

  ImageType::SizeType size;
  size[0] = 200;
  size[1] = 300;

  region.SetSize( size );
  region.SetIndex( start );

  ImageType::Pointer image = ImageType::New();
  image->SetRegions( region );
  image->Allocate();

  ImageType::IndexType ind;
  ind[0] = 10;
  ind[1] = 10;

  typedef  itk::ImageFileWriter< ImageType  > WriterType;
  WriterType::Pointer writer = WriterType::New();
  writer->SetFileName( absolutePathDoCrash );
  writer->SetInput( image );
  writer->Update();

  return EXIT_SUCCESS;
}

When I change the filename in the writer to the variable absolutePathNoCrash (one character shorter), the program runs without crash.

In both cases a Comment entry is added in the mhd file that contains the part of the file path from 256th character onward. No Comment entry in the mhd file, when the variable absolutePathNoComme is used as filename.

With all three path variables the mhd and raw file gets written.

No crash happens when the file extension is changed to png.

This was tested witk ITK 5.0RC2 on Ubuntu 18.04

1 Like

Additional information:

This problem also affects the vtkMetaImageWriter. See this post on the VTK Discourse.

Looking into it…

m_FileName in MetaObject is limited to 255 characters:


So setting it to something longer makes it spill over into m_Comment.

As we now require C++11, I this it is best if we use std::string there. Let me see if updating that requires a big refactoring.

Refactoring is not trivial. I created an issue to track this. Thanks for reporting @lukas!

1 Like

Hi Dženan,

Thank you for creating the issue.
Looking forward to the fix.

I modified MetaIO to use std::string for file names, but the limitation you described still persists. Call at line 1633 fails the check at line 1635. It resolves to std::ofstream constructor.

Failure to open a stream for writing has little to do with MetaIO’s code. Do the file system limits have anything to do with it? Anyway, you should be able to explore this issue by yourself now. And please review the PR.

1 Like

Thank you for the speedy modification!

As I am not familiar with the MetaIO sources, I can not comment on the pull request, but at least for my use case, your changes solve the problem I was having.

I replaced the MetaIO files in ITK5.0RC2 with the MetaIO source code from your commit 279e9ad.
Then I compiled ITK and ran the example code in the first post, as well as my own application.
In both cases the MHD files are now written correctly (no more Comment entry containing the end of the filename) and there is no segfault.

2 Likes