[ITK] Segmentation Fault at SpatialObject::New()

Bradley Lowekamp blowekamp at mail.nih.gov
Fri May 2 08:35:39 EDT 2014


Matt,

Why do you think such an intrinsic OS level call is miss-behaving?

I'm skeptical of that cause and think it's more likely that is some type of memory corruption going on.

Jin:

Please describe how you have compiled ITK and your test? Are you sure that you used the same compiler? Perhaps some flags changed? or perhaps you are mixing libraries accidentally? Are you ITK as static or share libraries? Have you recently performed any system updates?

I have seen people spend the better part of the day tracking down bugs, that were the result of inconsistent compilations due to changed libraries/headers.

Brad

On May 1, 2014, at 4:45 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:

> Hi Jin,
> 
> The OSAtomicDecrement64Barrier [1] might not be behaving, but why is
> this code being created?  Why is the only statement the creation of an
> object in a "while(true)"?  Does it still crash with other statements
> in the loop?
> 
> Thanks,
> Matt
> 
> [1] http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/src/itkLightObject.cxx;h=ce95746f71180f7084a5cdcc7d9f332356b049d3;hb=HEAD#l204
> 
> On Thu, May 1, 2014 at 2:24 PM, Jinwoo Choi
> <jinwoo.choi at mail.utoronto.ca> wrote:
>> Dear all,
>> 
>> I have the following simple code:
>> 
>> #include <itkSpatialObject.h>
>> int main(int argc, char *argv[])
>> {
>>  typedef itk::SpatialObject<2> SOT;
>>  while (true) {
>>    SOT::Pointer sot = SOT::New();
>>  }
>> }
>> 
>> Which results in a segmentation fault with the following stack trace:
>> 
>> #0  0x00007fff8986bce2 in __pthread_kill ()
>> #1  0x00007fff8dd237d2 in pthread_kill ()
>> #2  0x00007fff8dd14a7a in abort ()
>> #3  0x00007fff8dd7384c in free ()
>> #4  0x00000001093c2f69 in itk::LightObject::~LightObject (this=0x115f00370)
>> at /Users/jin/MyVTK/ITK/ITK/Modules/Core/Common/src/itkLightObject.cxx:254
>> #5  0x00000001093c2e7e in itk::LightObject::UnRegister (this=0x115f00370) at
>> /Users/jin/MyVTK/ITK/ITK/Modules/Core/Common/src/itkLightObject.cxx:206
>> #6  0x0000000100038e14 in itk::SmartPointer<itk::VectorContainer<unsigned
>> long, itk::Point<double, 2u> > >::UnRegister (this=0x7fff5fbff7b0) at
>> itkSmartPointer.h:157
>> #7  0x0000000100038dc9 in itk::SmartPointer<itk::VectorContainer<unsigned
>> long, itk::Point<double, 2u> > >::~SmartPointer (this=0x7fff5fbff7b0) at
>> itkSmartPointer.h:65
>> #8  0x0000000100038da5 in itk::SmartPointer<itk::VectorContainer<unsigned
>> long, itk::Point<double, 2u> > >::~SmartPointer (this=0x7fff5fbff7b0) at
>> itkSmartPointer.h:64
>> #9  0x000000010004cc04 in itk::BoundingBox<unsigned long, 2, double,
>> itk::VectorContainer<unsigned long, itk::Point<double, 2u> > >::BoundingBox
>> (this=0x115f00270) at itkBoundingBox.hxx:124
>> #10 0x000000010004cb15 in itk::BoundingBox<unsigned long, 2, double,
>> itk::VectorContainer<unsigned long, itk::Point<double, 2u> > >::BoundingBox
>> (this=0x115f00270) at itkBoundingBox.h:125
>> #11 0x0000000100028982 in itk::BoundingBox<unsigned long, 2, double,
>> itk::VectorContainer<unsigned long, itk::Point<double, 2u> > >::New () at
>> itkBoundingBox.h:90
>> #12 0x0000000100028097 in itk::SpatialObject<2u>::SpatialObject
>> (this=0x115f00000) at itkSpatialObject.hxx:35
>> #13 0x0000000100027e35 in itk::SpatialObject<2u>::SpatialObject
>> (this=0x115f00000) at itkSpatialObject.h:57
>> #14 0x0000000100027b32 in itk::SpatialObject<2u>::New () at
>> itkSpatialObject.h:137
>> #15 0x00000001000279df in main (argc=1, argv=0x7fff5fbffb30) at
>> /Users/jin/vurtigo/rtMain.cpp:64
>> #16 0x0000000100027924 in start ()
>> 
>> I have this issue with ITK4.2.1 and ITK 4.5.2, happens both Debug and
>> Release compilation.
>> 
>> Oddly, when I put a break point on (using gdb) itkSpatialObject.h:57 and
>> print m_Bounds, delete all break points, and continue (continue in the main
>> while loop), the segmentation fault stops occurring.
>> 
>> My platform is OSX 10.7.5, and I am using /usr/bin/c++ (which I believe is
>> clang), clang -v -version outputs the following:
>> Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
>> Target: x86_64-apple-darwin11.4.2
>> Thread model: posix
>> 
>> Any insights into this issue will be greatly appreciated!
>> 
>> Thank you,
>> 
>> Jin
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/community
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/community




More information about the Community mailing list