[Insight-users] ITK crash on Lion/Qt

[Christian Lackas]

* Christian Lackas <lackas at invicro.com> [111018 17:50]:

Hi Everybody,

thanks for all input. The ITK Object Factory was a dead end (there were
no factories and then itkNewMacro falls back to a regular 'new').
However, I finally found the issue and it is a tricky one, that can
affect all Mac users that use ITK together with Qt (in 64-bit
applications?).

What happens is that in itkLightObject.h ITK defines a type named
'InternalReferenceCountType' for the reference counting used by
itkSmartPointer. On my Snow Leopard Mac it is using:

    #if [windows] 
    #elif defined(__APPLE__) && (MAC_OS_X_VERSION_MIN_REQUIRED >= 1050)
     #if defined (__LP64__) && __LP64__
      typedef volatile int64_t InternalReferenceCountType;
     #else
      [32-bit version]
     #endif
    #elif defined(__GLIBCPP__) || defined(__GLIBCXX__)
      typedef _Atomic_word InternalReferenceCountType;
    #else


when building ITK itself, but unfortunately Qt forces
MAC_OS_X_VERSION_MIN_REQUIRED to be 10.4 in their qglobal.h (ignoring
any input of the user, although qmake actually has a
QMAKE_MACOSX_DEPLOYMENT_TARGET variable to set the value, but this value
is simply ignored):

    #ifdef Q_OS_DARWIN
    #  ifdef MAC_OS_X_VERSION_MIN_REQUIRED
    #    undef MAC_OS_X_VERSION_MIN_REQUIRED
    #  endif
    #  define MAC_OS_X_VERSION_MIN_REQUIRED MAC_OS_X_VERSION_10_4
    ...

This means that when using ITK with Qt headers included first you end up with
'_Atomic_word' instead of 'volatile int64_t', plus some additional
confusion in itkLightObject.cxx.

My guess now is that _Atomic_word is smaller in size then int64_t and on
Snow Leopard (10.6) the trailing bits where usually 0 (unless when used
MallocScribble, where it also crashed on this OS), while on Lion (where
it almost always crashed) they were non-0, thus totally screwing up the
reference counting.

To cut a long story short, removing Qt's force override of the min
required version from qglobal.h helped.

Will file a Qt bug report now.

Hope this helps other Mac/Qt/ITK users in the mean-time.

Christian

-- 
Dr. Christian Lackas, Managing Partner
inviCRO, LLC -- In Imaging Yours
P: +1 617 933 8733, F: +49 2203 9034722, E: lackas at invicro.com
http://www.invicro.com/  http://www.spect-ct.com/

> * Sean McBride <sean at rogue-research.com> [111018 17:35]:
> 
> Hi Sean,
> 
> thanks once again.
> 
> > BTW, I recommend always using MallocScribble in Debug, it only affects
> > performance minimally, and makes bugs repro much more easily.
> 
> yes, I like MallocScribble very much. Was not aware of it before, so
> thanks again for the hint and I fully agree.
> 
> > >(gdb) p *m_Pointer
> > >$2 = {
> > >  <itk::FiniteDifferenceFunction<itk::Image<float, 2u> >> = {
> > >    <itk::LightObject> = {
> > >      _vptr$LightObject = 0x5555555555555555,
> > As the docs explain, when MallocScribble is set, all memory created
> > with malloc/new is initialized to 0xAA and all freeed memory is set to
> > 0x55.  So _vptr$LightObject has been freed.  Is the code you're
> > running trying to use it after?
> 
> Yes, this is what causes the crash. The code is still within ITK,
> though.
> 
> Reading more through the object factory code of ITK, I found
> ObjectFactoryBase::CreateInstance(const char* itkclassname). This is
> where the problem starts, since it returns 0 for my filter I want to
> create. The itkclassname is
> 
>     N3itk21CurvatureFlowFunctionINS_5ImageIfLj2EEEEE
> 
> It is somehow possible that this classname is not recognized by any
> factory (e.g. since the signature is calculated slightly differently in
> the factory and where I use it)?
> 
> ITK does not seem to handle the case that no factory handles a creation.
> Is that supposed to be this way? Wondering if a warning before the
> ultimate 'return 0;' at ObjectFactoryBase::CreateInstance(...) would be
> of any use.
> 
> More important is of course the question why no factory believe it
> should create my filter.
> 
> Christian
> 
> -- 
> Dr. Christian Lackas, Managing Partner
> inviCRO, LLC -- In Imaging Yours
> P: +1 617 933 8733, F: +49 2203 9034722, E: lackas at invicro.com
> http://www.invicro.com/  http://www.spect-ct.com/