<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body >Hi Matt, thank you for the reply. <div><br></div><div>Initially the segfault was happening randomly as a part of a large software. I was trying to see if another statement somewhere in the codebase was causing this to segfault.</div><div>I tried to isolate the object creation code to see if it still segfaults. Hence the simple code I have posted. </div><div><br></div><div>Is there anyway to make sure that the atomic decrement barrier works as intended? </div><div><br></div><div>Thank you again, </div><div><br></div><div>Jin</div><br><br><br><br><br><br><br><br><br><br>-------- Original message --------<br>From: Matt McCormick <matt.mccormick@kitware.com> <br>Date:05/01/2014 4:45 PM (GMT-05:00) <br>To: Jinwoo Choi <jinwoo.choi@mail.utoronto.ca> <br>Cc: community@itk.org <br>Subject: Re: [ITK] Segmentation Fault at SpatialObject::New() <br><br>Hi Jin,<br><br>The OSAtomicDecrement64Barrier [1] might not be behaving, but why is<br>this code being created? Why is the only statement the creation of an<br>object in a "while(true)"? Does it still crash with other statements<br>in the loop?<br><br>Thanks,<br>Matt<br><br>[1] http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/src/itkLightObject.cxx;h=ce95746f71180f7084a5cdcc7d9f332356b049d3;hb=HEAD#l204<br><br>On Thu, May 1, 2014 at 2:24 PM, Jinwoo Choi<br><jinwoo.choi@mail.utoronto.ca> wrote:<br>> Dear all,<br>><br>> I have the following simple code:<br>><br>> #include <itkSpatialObject.h><br>> int main(int argc, char *argv[])<br>> {<br>> typedef itk::SpatialObject<2> SOT;<br>> while (true) {<br>> SOT::Pointer sot = SOT::New();<br>> }<br>> }<br>><br>> Which results in a segmentation fault with the following stack trace:<br>><br>> #0 0x00007fff8986bce2 in __pthread_kill ()<br>> #1 0x00007fff8dd237d2 in pthread_kill ()<br>> #2 0x00007fff8dd14a7a in abort ()<br>> #3 0x00007fff8dd7384c in free ()<br>> #4 0x00000001093c2f69 in itk::LightObject::~LightObject (this=0x115f00370)<br>> at /Users/jin/MyVTK/ITK/ITK/Modules/Core/Common/src/itkLightObject.cxx:254<br>> #5 0x00000001093c2e7e in itk::LightObject::UnRegister (this=0x115f00370) at<br>> /Users/jin/MyVTK/ITK/ITK/Modules/Core/Common/src/itkLightObject.cxx:206<br>> #6 0x0000000100038e14 in itk::SmartPointer<itk::VectorContainer<unsigned<br>> long, itk::Point<double, 2u> > >::UnRegister (this=0x7fff5fbff7b0) at<br>> itkSmartPointer.h:157<br>> #7 0x0000000100038dc9 in itk::SmartPointer<itk::VectorContainer<unsigned<br>> long, itk::Point<double, 2u> > >::~SmartPointer (this=0x7fff5fbff7b0) at<br>> itkSmartPointer.h:65<br>> #8 0x0000000100038da5 in itk::SmartPointer<itk::VectorContainer<unsigned<br>> long, itk::Point<double, 2u> > >::~SmartPointer (this=0x7fff5fbff7b0) at<br>> itkSmartPointer.h:64<br>> #9 0x000000010004cc04 in itk::BoundingBox<unsigned long, 2, double,<br>> itk::VectorContainer<unsigned long, itk::Point<double, 2u> > >::BoundingBox<br>> (this=0x115f00270) at itkBoundingBox.hxx:124<br>> #10 0x000000010004cb15 in itk::BoundingBox<unsigned long, 2, double,<br>> itk::VectorContainer<unsigned long, itk::Point<double, 2u> > >::BoundingBox<br>> (this=0x115f00270) at itkBoundingBox.h:125<br>> #11 0x0000000100028982 in itk::BoundingBox<unsigned long, 2, double,<br>> itk::VectorContainer<unsigned long, itk::Point<double, 2u> > >::New () at<br>> itkBoundingBox.h:90<br>> #12 0x0000000100028097 in itk::SpatialObject<2u>::SpatialObject<br>> (this=0x115f00000) at itkSpatialObject.hxx:35<br>> #13 0x0000000100027e35 in itk::SpatialObject<2u>::SpatialObject<br>> (this=0x115f00000) at itkSpatialObject.h:57<br>> #14 0x0000000100027b32 in itk::SpatialObject<2u>::New () at<br>> itkSpatialObject.h:137<br>> #15 0x00000001000279df in main (argc=1, argv=0x7fff5fbffb30) at<br>> /Users/jin/vurtigo/rtMain.cpp:64<br>> #16 0x0000000100027924 in start ()<br>><br>> I have this issue with ITK4.2.1 and ITK 4.5.2, happens both Debug and<br>> Release compilation.<br>><br>> Oddly, when I put a break point on (using gdb) itkSpatialObject.h:57 and<br>> print m_Bounds, delete all break points, and continue (continue in the main<br>> while loop), the segmentation fault stops occurring.<br>><br>> My platform is OSX 10.7.5, and I am using /usr/bin/c++ (which I believe is<br>> clang), clang -v -version outputs the following:<br>> Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)<br>> Target: x86_64-apple-darwin11.4.2<br>> Thread model: posix<br>><br>> Any insights into this issue will be greatly appreciated!<br>><br>> Thank you,<br>><br>> Jin<br>> _______________________________________________<br>> Community mailing list<br>> Community@itk.org<br>> http://public.kitware.com/cgi-bin/mailman/listinfo/community<br></body>