[Insight-developers] Help to debug on LInux64 and Mac 10.5

Thu Dec 20 08:16:48 EST 2007

Guys,

I just found this posting:
http://gcc.gnu.org/ml/gcc/2006-12/msg00459.html

That talks about integer overflow. I think this is relates to the hash
problem.

Bill

On Dec 20, 2007 8:03 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:

> Also, the hash for the Algortihms test does not overflow. This may explain
> why that test passes on the 64 bit systems. The length of the key for
> itkMesh is 12 while the length of the key for itkQuadEdgeMesh is 20.
>
>
> On Dec 20, 2007 12:16 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> > Maybe the hash function in Code/Common/itkStructHashFunction.h is
> > failing some how. The computation of the hash can cause an integer overflow
> > I believe. Maybe the results are not predictable?
> >
> > Bill
> >
> >   On Dec 19, 2007 8:57 PM, Hans Johnson <hans-johnson at uiowa.edu> wrote:
> >
> > > Alexandre,
> > >
> > > FYI:  IRIX64 is a 64 bit operating system, but the code is compiled
> > > with a
> > > 32bit address space.
> > >
> > > Hans
> > >
> > > On 12/19/07 7:48 PM, "Alexandre GOUAILLARD" <hanfei at caltech.edu>
> > > wrote:
> > >
> > > > Hi sean,
> > > >
> > > > And thanks for your quick reply.
> > > > I thought about the 64 bits issue, but the test seems to pass ok on
> > > the
> > > > following machines:
> > > > Kraepelin.uiowa    IRIX64
> > > > crunch1.isi.nl     linux64-g++- 4.0.2
> > > >
> > > > The output of the test shows that some points are duplicated. Even
> > > funnier,
> > > > the number of duplicated points is not the same depending on the
> > > > configuration (deb/rel).
> > > >
> > > > Site Name: RogueResearch4
> > > > Build Name: Mac10.5-InsightBS-dbg
> > > > 0: [0, 0, 1]
> > > > 1: [0, 1, 0]
> > > > 2: [1, 0, 0]
> > > > 3: [0, 0, 0]
> > > > 4: [0, 0, 1]   *** #0
> > > > 5: [1, 1, 1]
> > > > 6: [3, 1, 1]
> > > > 7: [2, 1, 1]
> > > > 8: [3, 0, 1]
> > > > 9: [2, 0, 1]
> > > > 10: [3, 1, 0]
> > > > 11: [2, 1, 0]
> > > > 12: [3, 0, 0]
> > > > 13: [2, 0, 0]
> > > > 14: [4, 1, 1]
> > > > 15: [3, 1, 1]  *** #6
> > > > 16: [4, 0, 1]
> > > > 17: [4, 1, 0]
> > > > 18: [4, 0, 0]
> > > >
> > > >
> > > > Site Name: RogueResearch4
> > > > Build Name: Mac10.5-InsightBS-rel
> > > > 20 points:
> > > > 0: [0, 0, 1]
> > > > 1: [0, 1, 0]
> > > > 2: [1, 0, 0]
> > > > 3: [0, 0, 0]
> > > > 4: [0, 0, 1]  *** #0
> > > > 5: [0, 1, 0]  *** #1
> > > > 6: [1, 0, 0]  *** #2
> > > > 7: [1, 1, 1]
> > > > 8: [3, 1, 1]
> > > > 9: [2, 1, 1]
> > > > 10: [3, 0, 1]
> > > > 11: [2, 0, 1]
> > > > 12: [3, 1, 0]
> > > > 13: [2, 1, 0]
> > > > 14: [3, 0, 0]
> > > > 15: [2, 0, 0]
> > > > 16: [4, 1, 1]
> > > > 17: [4, 0, 1]
> > > > 18: [4, 1, 0]
> > > > 19: [4, 0, 0]
> > > >
> > > > There is no Id checking at the point container level, so I suspect
> > > the
> > > > itk::AutomaticTopologyMeshSource<>::AddPoint() method
> > > > (Code\Algorithms\itkAutomaticTopologyMeshSource.txx:52) not to do
> > > its job
> > > > correctly.
> > > >
> > > > Strange, because the original test does not fail .... Might be
> > > because point
> > > > container type by defualt in the itk::mesh and itk::QuadEdgeMesh are
> > > > different?
> > > >
> > > > If you had time, would you mind to take a look at what happen there?
> > > >
> > > > Alex.
> > > >
> > > >
> > > > On 12/19/07 5:04 PM, "Sean McBride" <sean at rogue-research.com> wrote:
> > > >
> > > >> On 12/19/07 4:28 PM, Alexandre GOUAILLARD said:
> > > >>
> > > >>> The "itkAutomaticTopologyQuadEdgeMeshSourceTest" test is failling
> > > on the two
> > > >>> following machines:
> > > >>> Boa,invivonmr.uu.nl
> > > >>> RogueResearch4
> > > >>>
> > > >>> Unfortunatly, I don t have corresponding configuration available
> > > here
> > > >>> (linux-x86, 64bits, g++4.1 and Mac OS10.5 Insight BS deb/rel).
> > > >>>
> > > >>> Could the owner of those machine give me acces to them
> > > >>
> > > >> Probably not... :(
> > > >>
> > > >>> or give me a hand to
> > > >>> track those errors?
> > > >>
> > > >> Sure!
> > > >>
> > > >> RogueResearch4 does a few ITK builds.  InsightBS-dbg and
> > > InsightReview-
> > > >> gcc-dbg-rosetta are very similar, the only real difference is that
> > > the
> > > >> former builds 64 bit executables and the latter 32 bit.  Your test
> > > is
> > > >> failing only on the former.  Since the linux machine is also
> > > building 64
> > > >> bit, my guess would be that 64 bit-ness is the problem.
> > > >>
> > > >> On the Mac, the major difference between 32 and 64 bit is that the
> > > >> 'long' type changes size (so does any pointer, size_t, etc.  But
> > > float,
> > > >> double, char, short, and int stay the same).  You might want to
> > > check
> > > >> everywhere you use 'int' and 'long' to be sure you aren't mixing
> > > them
> > > >> up.  I checked very fast, and see you do:
> > > >>
> > > >>   int numPoints = meshSource->GetOutput()->GetNumberOfPoints();
> > > >>
> > > >> However, GetNumberOfPoints() returns a long not an int.  This
> > > should be
> > > >> fixed, but probably isn't the problem.
> > > >>
> > > >> I there some test I can run for you?
> > > >>
> > > >> --
> > > >> ____________________________________________________________
> > > >> Sean McBride, B. Eng                 sean at rogue-research.com
> > > >> Rogue Research                         www.rogue-research.com
> > > >> Mac Software Developer              Montréal, Québec, Canada
> > > >>
> > > >
> > > >
> > > > _______________________________________________
> > > > Insight-developers mailing list
> > > > Insight-developers at itk.org
> > > > http://www.itk.org/mailman/listinfo/insight-developers
> > >
> > > _______________________________________________
> > > Insight-developers mailing list
> > > Insight-developers at itk.org
> > > http://www.itk.org/mailman/listinfo/insight-developers
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.itk.org/mailman/private/insight-developers/attachments/20071220/354f6e69/attachment.htm