[ITK-dev] ITK Static Initialization Issue with pthreads and atomic ints

[Matt McCormick]

Hi Brad,

Sujin took a look, and he spotted a missing initialization of the
mutex lock for the 32 bit case.  I put the change in a patch here:

  http://review.source.kitware.com/#/c/20039/

Please test on the 32 bit system.

Thanks,
Matt

On Fri, Jul 31, 2015 at 10:55 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Greeting,
>
> I am investigating the test failures:
>
> https://open.cdash.org/viewTest.php?onlyfailed&buildid=3931664
>
> Which began occurring with upgrade to ITK 4.8.
>
> Doing a git bisect I narrowed the problem down to the change to the atomic
> integer class done here:
>
> https://github.com/InsightSoftwareConsortium/ITK/commit/33bcbd822f761e407db851d218b1e3204e6194d9
>
> Then I was able to get a stack trace for a failing ITK test:
>
> (gdb)
> #0  0x00a77d2d in pthread_mutex_lock () from /lib/libpthread.so.0
> #1  0x086cede3 in itk::SimpleFastMutexLock::Lock (this=0x0) at
> /home/blowekamp/src/ITK/Modules/Core/Common/src/itkSimpleFastMutexLockPThreads.cxx:50
> #2  0x0869976c in
> itk::MutexLockHolder<itk::SimpleFastMutexLock>::MutexLockHolder
> (this=0xbfffe6fc, mutex=..., noblock=false)
>     at
> /home/blowekamp/src/ITK/Modules/Core/Common/include/itkMutexLockHolder.h:56
> #3  0x086d4308 in itk::Detail::AtomicOps<4u>::PreIncrement (ref=0x8982c78)
> at /home/blowekamp/src/ITK/Modules/Core/Common/src/itkAtomicInt.cxx:214
> #4  0x086c7e45 in itk::AtomicInt<unsigned long>::operator++ (this=0x8982c78)
> at /home/blowekamp/src/ITK/Modules/Core/Common/include/itkAtomicInt.h:93
> #5  0x086c7dd6 in itk::TimeStamp::Modified (this=0x8c81980) at
> /home/blowekamp/src/ITK/Modules/Core/Common/src/itkTimeStamp.cxx:63
> #6  0x086a11fb in itk::Object::Modified (this=0x8c81970) at
> /home/blowekamp/src/ITK/Modules/Core/Common/src/itkObject.cxx:389
> #7  0x086a1346 in itk::Object::Object (this=0x8c81970) at
> /home/blowekamp/src/ITK/Modules/Core/Common/src/itkObject.cxx:593
> #8  0x086c9be6 in itk::ObjectFactoryBase::ObjectFactoryBase (this=0x8c81970)
>     at
> /home/blowekamp/src/ITK/Modules/Core/Common/src/itkObjectFactoryBase.cxx:476
> #9  0x08379b12 in itk::MetaImageIOFactory::MetaImageIOFactory
> (this=0x8c81970)
>     at
> /home/blowekamp/src/ITK/Modules/IO/Meta/src/itkMetaImageIOFactory.cxx:24
> #10 0x08296048 in itk::MetaImageIOFactory::New () at
> /home/blowekamp/src/ITK/Modules/IO/Meta/include/itkMetaImageIOFactory.h:46
> #11 0x08224ae0 in RegisterRequiredFactories ()
>     at
> /home/blowekamp/src/ITK/Modules/Core/TestKernel/include/itkTestDriverIncludeRequiredIOFactories.h:41
> #12 0x08229720 in ProcessArgumentsAndRegisterRequiredFactories
> (ac=0xbfffeaf0, av=0xbfffeaf4)
>     at
> /home/blowekamp/src/ITK/Modules/Core/TestKernel/include/itkTestDriverIncludeRequiredIOFactories.h:58
> #13 0x082297f7 in main (ac=1, av=0xbfffeb74) at
> /scratch/blowekamp/build/Modules/Video/Core/test/ITKVideoCoreTestDriver.cxx:102
>
> So, this stack trace shows that there is a problem using pthreads during
> static initialization for the Object's reference counting.
>
> As the implementation is basically that of VTK, I and wondering if anyone
> else knows about this problem or work arounds.
>
> Thanks,
> Brad