[Insight-developers] Help to debug on LInux64 and Mac 10.5
Bill Lorensen
bill.lorensen at gmail.com
Thu Dec 20 08:46:46 EST 2007
Sean,
It looks like the undefined behavior is only for signed integer overflow.
Could you try something for us?
In Code/Common/itkStructHashFunction.h, change the line:
int hash = 0;
to
unsigned int hash = 0;
and rerun the failing test.
Thanks,
Bill
On Dec 20, 2007 8:16 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> 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/c1dfa287/attachment-0001.html
More information about the Insight-developers
mailing list