[Insight-users] ITK crash on Lion/Qt

Simon ESNEAULT simon.esneault at gmail.com
Wed Nov 30 09:02:39 EST 2011


Hi Christian,

We were affected too here, also with the CurvatureFlowImageFilter, Qt
4.7.4, ITK 3.20.1 and Mac OSX Lion.
So thanks a lot for solving this issue, its erratic behaviour was making it
very difficult to catch !

-Simon



On Tue, Oct 18, 2011 at 22:31, Christian Lackas <lackas at invicro.com> wrote:

> * 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/
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>



-- 
------------------------------------------------------------------
Simon Esneault
13 rue Vasselot
35000 Rennes, France
Tel : 06 64 61 30 94
Mail : simon.esneault at gmail.com
------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20111130/2a0cbb14/attachment.htm>


More information about the Insight-users mailing list