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 <blowek...@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 _______________________________________________ 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://kitware.com/products/protraining.php 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://public.kitware.com/mailman/listinfo/insight-developers