[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FEM debian test failures



On Sat, Jun 09, 2012 at 08:57:01AM -0400, Bill Lorensen wrote:

> We need someone to run the spatial object tests in a debugger to
> give us a hint.

Well, I spent some time looking at itkReadWriteSpatialObjectTest and
I've determined a few things.

1. It works when built using gcc 4.6 in Release mode (flags -O3 -DNDEBUG).
2. It works when built using gcc 4.7 in RelWithDebInfo mode (flags -O2 -g).
3. It fails when built using gcc 4.7 in Release mode.
4. It fails when built using gcc 4.7 with flags -O3 -g -DNDEBUG.

The stack trace is:

(gdb) set args itkReadWriteSpatialObjectTest /home/steve/Packages/insighttoolkit/upstream/ITK/build/Testing/Temporary/Objects.meta
(gdb) run
Starting program: /home/steve/Packages/debian-med/trunk/packages/insighttoolkit/upstream/ITK/build/bin/ITKIOSpatialObjectsTestDriver itkReadWriteSpatialObjectTest /home/steve/Packages/insighttoolkit/upstream/ITK/build/Testing/Temporary/Objects.meta
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 --- Testing Read-Write SpatialObject ---

Program received signal SIGSEGV, Segmentation fault.
itk::ScalableAffineTransform<double, 3u>::ComputeMatrix (this=0xebb6b0) at /home/steve/Packages/insighttoolkit/upstream/ITK/Modules/Core/Transform/include/itkScalableAffineTransform.hxx:180
180     ScalableAffineTransform< TScalarType, NDimensions >
(gdb) bt
#0  itk::ScalableAffineTransform<double, 3u>::ComputeMatrix (this=0xebb6b0) at /home/steve/Packages/insighttoolkit/upstream/ITK/Modules/Core/Transform/include/itkScalableAffineTransform.hxx:180
#1  0x00000000005949a3 in itk::ScalableAffineTransform<double, 3u>::SetScale (this=0xebb6b0, scale=<optimized out>) at /home/steve/Packages/insighttoolkit/upstream/ITK/Modules/Core/Transform/include/itkScalableAffineTransform.hxx:152
#2  0x00000000005e29b6 in itk::SpatialObject<3u>::ComputeObjectToParentTransform (this=this@entry=0xebafd0) at /home/steve/Packages/insighttoolkit/upstream/ITK/Modules/Core/SpatialObjects/include/itkSpatialObject.hxx:439
#3  0x00000000005ac28c in itk::ImageSpatialObject<3u, unsigned short>::SetImage (this=0xebafd0, image=<optimized out>) at /home/steve/Packages/insighttoolkit/upstream/ITK/Modules/Core/SpatialObjects/include/itkImageSpatialObject.hxx:304
#4  0x00000000005af6bd in SetImage (image=<optimized out>, this=<optimized out>) at /home/steve/Packages/insighttoolkit/upstream/ITK/Modules/Core/SpatialObjects/include/itkImageSpatialObject.hxx:257
#5  itkReadWriteSpatialObjectTest (argc=2, argv=0x7fffffffe3f0) at /home/steve/Packages/insighttoolkit/upstream/ITK/Modules/IO/SpatialObjects/test/itkReadWriteSpatialObjectTest.cxx:282
#6  0x00000000004e95ce in main (ac=2, av=0x7fffffffe3f0) at /home/steve/Packages/insighttoolkit/upstream/ITK/build/Modules/IO/SpatialObjects/test/ITKIOSpatialObjectsTestDriver.cxx:152


Valgrind reports a bad read:

steve@riemann{build}valgrind /home/steve/Packages/insighttoolkit/upstream/ITK/build/bin/ITKIOSpatialObjectsTestDriver "itkReadWriteSpatialObjectTest" "/home/steve/Packages/insighttoolkit/upstream/ITK/build/Testing/Temporary/Objects.meta"
==21659== Memcheck, a memory error detector
==21659== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==21659== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==21659== Command: /home/steve/Packages/insighttoolkit/upstream/ITK/build/bin/ITKIOSpatialObjectsTestDriver itkReadWriteSpatialObjectTest /home/steve/Packages/insighttoolkit/upstream/ITK/build/Testing/Temporary/Objects.meta
==21659== 
 --- Testing Read-Write SpatialObject ---
==21659== Invalid read of size 8
==21659==    at 0x595BD2: itk::ScalableAffineTransform<double, 3u>::ComputeMatrix() (itkScalableAffineTransform.hxx:180)
==21659==    by 0x5949A2: itk::ScalableAffineTransform<double, 3u>::SetScale(double const*) (itkScalableAffineTransform.hxx:152)
==21659==    by 0x5E29B5: itk::SpatialObject<3u>::ComputeObjectToParentTransform() (itkSpatialObject.hxx:439)
==21659==    by 0x5AC28B: _ZN3itk18ImageSpatialObjectILj3EtE8SetImageEPKNS_5ImageItLj3EEE.part.518 (itkImageSpatialObject.hxx:304)
==21659==    by 0x5AF6BC: itkReadWriteSpatialObjectTest(int, char**) (itkImageSpatialObject.hxx:257)
==21659==    by 0x4E95CD: main (ITKIOSpatialObjectsTestDriver.cxx:152)
==21659==  Address 0x808f5cff8 is not stack'd, malloc'd or (recently) free'd
==21659== 
==21659== 
==21659== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==21659==  Access not within mapped region at address 0x808F5CFF8
==21659==    at 0x595BD2: itk::ScalableAffineTransform<double, 3u>::ComputeMatrix() (itkScalableAffineTransform.hxx:180)
==21659==    by 0x5949A2: itk::ScalableAffineTransform<double, 3u>::SetScale(double const*) (itkScalableAffineTransform.hxx:152)
==21659==    by 0x5E29B5: itk::SpatialObject<3u>::ComputeObjectToParentTransform() (itkSpatialObject.hxx:439)
==21659==    by 0x5AC28B: _ZN3itk18ImageSpatialObjectILj3EtE8SetImageEPKNS_5ImageItLj3EEE.part.518 (itkImageSpatialObject.hxx:304)
==21659==    by 0x5AF6BC: itkReadWriteSpatialObjectTest(int, char**) (itkImageSpatialObject.hxx:257)
==21659==    by 0x4E95CD: main (ITKIOSpatialObjectsTestDriver.cxx:152)
==21659==  If you believe this happened as a result of a stack
==21659==  overflow in your program's main thread (unlikely but
==21659==  possible), you can try to increase the size of the
==21659==  main thread stack using the --main-stacksize= flag.
==21659==  The main thread stack size used in this run was 8388608.
==21659== 


However, the reported line 180 of itkScalableAffineTransform.hxx is
the start of method ComputeMatrix(), so I can't figure out where the
bad address came from.

GCC is Debian 4.7.0-12.  I'm not sure gcc 4.7 is very well tested:
there have been a flurry of uploads with patches to fix gcc problem
reports.  So it's certainly possible this is a gcc bug.

-Steve

Attachment: signature.asc
Description: Digital signature


Reply to: