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

[Bill Lorensen]

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/dced6f03/attachment.html