[Insight-users] Segfault in ~DICOMImageIO2 when loading PNG if ITK imported after VTK

[Charl P. Botha]

--=-m+q9jcqdFZQdtXRbYbaR
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Dear list,

Attached is a very simple Python sample (the INSIGHT_ROOT variable has
to be set to your Insight source directory).  With latest CVS ITK, VTK
and Python wrappings compiled, this segfaults.  See the attached
backtrace.

The segfault occurs in the DICOMImageIO2 dtor when this->AppHelper is
deleted, even when a non-DICOM image is loaded, for example a PNG.  This
is obviously because the image loaders are tried in turn until one
works.  

If one imports InsightToolkit BEFORE importing vtk however, there is no
segfault.  This looks like it could have something to do with the
DICOMParser and DICOMAppHelper which are present in both VTK and ITK.

Does anyone have any ideas about this bug?  Unfortunately, it doesn't
seem like the CMake setup supports easily disabling the DICOM support
anymore.

Thanks,
Charl

-- 
charl p. botha http://cpbotha . net/ http://visualisation . tudelft . nl/


--=-m+q9jcqdFZQdtXRbYbaR
Content-Disposition: attachment; filename=testDICOMBreakage.py
Content-Type: text/x-python; name=testDICOMBreakage.py; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

import os
import vtk
from InsightToolkit import *

INSIGHT_ROOT=3D"/home/cpbotha/build/Insight/"

reader2 =3D itkImageFileReaderF2_New()
reader2.SetFileName(os.path.join(INSIGHT_ROOT, "Testing/Data/Input/cthead1.=
png"))
reader2.Update()

--=-m+q9jcqdFZQdtXRbYbaR
Content-Disposition: attachment; filename=DICOMBreakage.backtrace.txt
Content-Type: text/plain; name=DICOMBreakage.backtrace.txt; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 9315)]
0x478e7860 in itk::DICOMImageIO2::~DICOMImageIO2 (this=0x9ecf7d8, __in_chrg=3)
    at /home/cpbotha/DoNotBackup/build/Insight/Code/IO/itkDICOMImageIO2.cxx:57
57        delete this->AppHelper;
Current language:  auto; currently c++
(gdb) bt
#0  0x478e7860 in itk::DICOMImageIO2::~DICOMImageIO2 (this=0x9ecf7d8, __in_chrg=3)
    at /home/cpbotha/DoNotBackup/build/Insight/Code/IO/itkDICOMImageIO2.cxx:57
#1  0x439f5195 in itk::LightObject::UnRegister (this=0x9ecf7d8)
    at /home/cpbotha/DoNotBackup/build/Insight/Code/Common/itkLightObject.cxx:145
#2  0x43a03ef5 in itk::Object::UnRegister (this=0x9ecf7d8) at /home/cpbotha/DoNotBackup/build/Insight/Code/Common/itkObject.cxx:303
#3  0x4796559e in _List_base<itk::SmartPointer<itk::ImageIOBase>, allocator<itk::SmartPointer<itk::ImageIOBase> > >::clear (
    this=0xbfffebfc) at /home/cpbotha/DoNotBackup/build/Insight/Code/Common/itkSmartPointer.h:160
#4  0x479642ca in itk::ImageIOFactory::CreateImageIO (path=0x821d3c0 "/home/cpbotha/build/Insight/Testing/Data/Input/cthead1.png", 
    mode=<incomplete type>) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/stl_list.h:192
#5  0x4760b193 in itk::ImageFileReader<itk::Image<float, 2>, itk::DefaultConvertPixelTraits<float> >::GenerateOutputInformation (
    this=0x811d3a0) at /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3/std/bastring.h:339
#6  0x43a15f2e in itk::ProcessObject::UpdateOutputInformation (this=0x811d3a0)
    at /home/cpbotha/DoNotBackup/build/Insight/Code/Common/itkProcessObject.cxx:626
#7  0x431b6149 in itk::ImageBase<2>::UpdateOutputInformation (this=0x9ecd290)
    at /home/cpbotha/DoNotBackup/build/Insight/Code/Common/itkImageBase.txx:128
#8  0x439dde53 in itk::DataObject::Update (this=0x9ecd290) at /home/cpbotha/DoNotBackup/build/Insight/Code/Common/itkDataObject.cxx:325
#9  0x43a15c8e in itk::ProcessObject::Update (this=0x811d3a0)
    at /home/cpbotha/DoNotBackup/build/Insight/Code/Common/itkProcessObject.cxx:490
#10 0x475e6909 in _wrap_itkImageFileReaderF2_Pointer_Update (self=0x0, args=0x811f58c)
    at /home/cpbotha/DoNotBackup/build/Insight-gcc/Wrapping/CSwig/IO/wrap_itkImageFileReaderPython.cxx:11308
#11 0x080c7a04 in PyCFunction_Call ()

--=-m+q9jcqdFZQdtXRbYbaR--