# ImageFileWriter crashes when writing MHD file to long absolute path

**URL:** <https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856>\
**Category:** Beginner Questions\
**Created:** [May 9, 2019, 3:37pm UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856 "2019-05-09T15:37:41Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![lukas](https://discourse.itk.org/letter_avatar_proxy/v4/letter/l/e9a140/32.png) [@lukas](https://discourse.itk.org/u/lukas)\
**Post date:** [May 9, 2019, 3:37pm UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/1 "2019-05-09T15:37:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![lukas](https://discourse.itk.org/letter_avatar_proxy/v4/letter/l/e9a140/32.png) [@lukas](https://discourse.itk.org/u/lukas)\
**Post date:** [May 10, 2019, 6:28am UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/2 "2019-05-10T06:28:52Z")

</div>

Additional information:

This problem also affects the vtkMetaImageWriter. See [this](https://discourse.vtk.org/t/vtkmetaimagewriter-crashes-when-writing-mhd-file-to-long-absolute-path/943) post on the VTK Discourse.

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [May 10, 2019, 2:16pm UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/3 "2019-05-10T14:16:48Z")

</div>

Looking into it…

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [May 10, 2019, 2:32pm UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/4 "2019-05-10T14:32:03Z")

</div>

`m_FileName` in MetaObject is limited to 255 characters:

> <https://github.com/InsightSoftwareConsortium/ITK/blob/5c6be79b5adf561b838e4df402bb9b8c9491e34a/Modules/ThirdParty/MetaIO/src/MetaIO/src/metaObject.h#L48-L50>

  
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.

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [May 10, 2019, 2:53pm UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/5 "2019-05-10T14:53:31Z")

</div>

Refactoring is not trivial. I created an [issue](https://github.com/InsightSoftwareConsortium/ITK/issues/852) to track this. Thanks for reporting @lukas!

---

<div class="post-metadata">

**Author:** ![lukas](https://discourse.itk.org/letter_avatar_proxy/v4/letter/l/e9a140/32.png) [@lukas](https://discourse.itk.org/u/lukas)\
**Post date:** [May 13, 2019, 6:21am UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/6 "2019-05-13T06:21:21Z")

</div>

Hi Dženan,

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

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [May 13, 2019, 1:17pm UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/7 "2019-05-13T13:17:14Z")

</div>

I modified MetaIO to use `std::string` for file names, but the limitation you described still persists. [Call at line 1633](https://github.com/InsightSoftwareConsortium/ITK/blob/c6a59152c067049a869ebe42de393f36fad34e4e/Modules/ThirdParty/MetaIO/src/MetaIO/src/metaImage.cxx#L1633) fails the [check at line 1635](https://github.com/InsightSoftwareConsortium/ITK/blob/c6a59152c067049a869ebe42de393f36fad34e4e/Modules/ThirdParty/MetaIO/src/MetaIO/src/metaImage.cxx#L1635). It [resolves](https://github.com/InsightSoftwareConsortium/ITK/blob/c6a59152c067049a869ebe42de393f36fad34e4e/Modules/ThirdParty/MetaIO/src/MetaIO/src/metaImage.cxx#L54-L85) to `std::ofstream` constructor.

Failure to open a stream for writing has little to do with MetaIO’s code. Do the [file system limits](https://serverfault.com/questions/9546/filename-length-limits-on-linux) have anything to do with it? Anyway, you should be able to explore this issue by yourself now. And please review the [PR](https://github.com/Kitware/MetaIO/pull/74).

---

<div class="post-metadata">

**Author:** ![lukas](https://discourse.itk.org/letter_avatar_proxy/v4/letter/l/e9a140/32.png) [@lukas](https://discourse.itk.org/u/lukas)\
**Post date:** [May 14, 2019, 10:00am UTC](https://discourse.itk.org/t/imagefilewriter-crashes-when-writing-mhd-file-to-long-absolute-path/1856/8 "2019-05-14T10:00:58Z")

</div>

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.