Bugs on Mac OS X 64-bit Release build

[mindabuse]

Came across some Chipmunk bugs in a project when taking the Mac OS X 64-bit release build for a whirl. The 64-bit debug build never showed any problems. The bugs effect both physics and rendering.

Started to do some investigating. Eventually got a clean pull of Chipmunk-Physics from the git repo and fired up ChipmunkDemo 64-bit release and confirmed that the problems lie in Chipmunk.

I jumped over to chipmunk_types.h and disabled all #define's for CP_USE_CG_POINTS and CP_USE_DOUBLES. Never defining either seems to fix the problem with 64-bit release. Switching between defining only one of the two changed the bug but did not fix it. Both #define's had to be disabled.

My system is Mac OS X Lion 10.7.1 with Xcode 4.1 and using Apple LLVM compiler 2.1.

Hope this is enough info to repo on anyone else's side....

[slembcke]

Thats weird. What version of Chipmunk and what is CGFloat defined as on your system?

It should be something like the following in CGBase.h:

Code: Select all

#if defined(__LP64__) && __LP64__
# define CGFLOAT_TYPE double
# define CGFLOAT_IS_DOUBLE 1
# define CGFLOAT_MIN DBL_MIN
# define CGFLOAT_MAX DBL_MAX
#else /* !defined(__LP64__) || !__LP64__ */
# define CGFLOAT_TYPE float
# define CGFLOAT_IS_DOUBLE 0
# define CGFLOAT_MIN FLT_MIN
# define CGFLOAT_MAX FLT_MAX
#endif /* !defined(__LP64__) || !__LP64__ */

You definitely want to be using doubles for Chipmunk on desktop CPUs as they are faster and the extra memory use and bandwidth isn't a problem.

[mindabuse]

What version of Chipmunk and what is CGFloat defined as on your system?

Chipmunk is latest from your git repo (https://github.com/slembcke/Chipmunk-Physics), so 6.0.1+?

CGFloat is as follows at the bottom of CoreGraphics.framework/CGBase.h. Looks identical?

#if defined(__LP64__) && __LP64__
# define CGFLOAT_TYPE double
# define CGFLOAT_IS_DOUBLE 1
# define CGFLOAT_MIN DBL_MIN
# define CGFLOAT_MAX DBL_MAX
#else /* !defined(__LP64__) || !__LP64__ */
# define CGFLOAT_TYPE float
# define CGFLOAT_IS_DOUBLE 0
# define CGFLOAT_MIN FLT_MIN
# define CGFLOAT_MAX FLT_MAX
#endif /* !defined(__LP64__) || !__LP64__ */

typedef CGFLOAT_TYPE CGFloat;
#define CGFLOAT_DEFINED 1

[slembcke]

I'm a bit baffled because I always run the 64 bit build.

Can you add this to both the Chipmunk source somewhere (like in cpSpaceInit()) and in your own program?

Code: Select all

printf("sizeof(cpFloat): %d\n", sizeof(cpFloat);
printf("sizeof(cpVect): %d\n", sizeof(cpVect);

I suspect that the library is getting compiled with different typedefs than the rest of your program.

[mindabuse]

I'm a bit baffled because I always run the 64 bit build.

Can you add this to both the Chipmunk source somewhere (like in cpSpaceInit()) and in your own program?

Code: Select all

printf("sizeof(cpFloat): %d\n", sizeof(cpFloat);
printf("sizeof(cpVect): %d\n", sizeof(cpVect);

I suspect that the library is getting compiled with different typedefs than the rest of your program.

Same results in both:
sizeof(cpFloat): 8
sizeof(cpVect): 16

Just to double check - have you run the 'Release' build (vs. Debug) -- and see that I reproduced this issue in the stock ChipmunkDemo target with a clean copy of Chipmunk? The issues only show up in Release.

Here's what I did to repro:
1. Pull down a clean copy of Chipmunk-Physics (git clone https://github.com/slembcke/Chipmunk-Physics.git)
2. Open Chipmunk6.xcodeproj
3. Change the Target to ChipmunkDemo > My Mac 64-bit
4. Edit Scheme, Run ChipmunkDemo, Change Build Configuration from Debug to Release, OK
5. Run ChipmunkDemo. Logo Smash might seem okay but check the other demos. None of the others initialize properly.

You'll notice that circle shapes appear to be unaffected. Box/poly and segment shapes all are bonkers.

[slembcke]

Hmm. Still cannot reproduce.

Next best guess is that it's the drawing code. It has stuff like this in it:

Code: Select all

#if CP_USE_DOUBLES
	glVertexPointer(2, GL_DOUBLE, 0, verts);
#else
	glVertexPointer(2, GL_FLOAT, 0, verts);
#endif

[mindabuse]

Hmm. Still cannot reproduce.

Next best guess is that it's the drawing code. It has stuff like this in it:

Code: Select all

#if CP_USE_DOUBLES
	glVertexPointer(2, GL_DOUBLE, 0, verts);
#else
	glVertexPointer(2, GL_FLOAT, 0, verts);
#endif

I can say that what I'm seeing rules out just the drawing code. Any circles in the scene drop and fall off-screen when spawned (when there is appropriate gravity). You can see colors glitch for a brief moment for any color-filled shape.

I drilled down to the problem being with the Apple LLVM compiler 2.1. Switching the compiler to GCC 4.2 or LLVM GCC 4.2 eliminates the problem. Switching back to Apple LLVM compiler 2.1 manifests the problem again.

Perhaps this is a bug with Apple's compiler?

[slembcke]

Hmm. It's possible, but unlikely. Compiler bugs are generally pretty rare. I've really only found one case where I was sure the compiler was outputting bad assembly. It was in the Apple GCC 4.2 version ensuring that it would never get fixed anyway. (GCC 4.2 is ancient, Apple's been clinging to it because the newer versions are GPL3 and they were developing Clang instead.)

I'll poke around some more and see if I can reproduce it.

[mindabuse]

Hmm. It's possible, but unlikely. Compiler bugs are generally pretty rare. I've really only found one case where I was sure the compiler was outputting bad assembly.
....
I'll poke around some more and see if I can reproduce it.

I'm a registered Apple Developer and was able to get someone on the Apple developer forums to reproduce the problem. I haven't found out what exact combination of OS and Xcode build was used yet, but mine is Mac OS X Lion 10.7.1 11B26 with Xcode 4.1 4B110 (the Mac App Store version).

While on the Apple forum I did see mention of a separate, confirmed compiler bug in Mid-July related to code optimization and an incorrect square root calculation. Total shot in the dark, but perhaps this could be related?

The reproducible sample code is:

Code: Select all

#include <stdio.h>
#include <math.h>

#define VSCL(a,x)             ((a)[0]*= (x),   (a)[1]*= (x),   (a)[2]*= (x))
#define VDOT(a,b)             ((a)[0]*(b)[0] + (a)[1]*(b)[1] + (a)[2]*(b)[2])

typedef float           FVector[3];

        float
VMagDirF (
        FVector                  v)
{
        double                   mag, x;

        x = VDOT (v, v);
        printf ("v= [%g, %g, %g] x = %g\n", v[0], v[1], v[2], x);
        mag = sqrt (x);
        printf ("mag = %g (should be 0.000745818) \n", mag);

        return mag;
}

int main (int argc, const char * argv[]) {
        double                   mag;
        float                    v[3] = {0.00054734, 0.000283324, 0.000419989};

        mag = VMagDirF (v);

        return 0;
}
 

It was compiled with this command:

Code: Select all

clang -O3 test.c

The output from clang 2.1 (the version that appears to ship with Xcode 4.1) is this:

Code: Select all

v= [0.00054734, 0.000283324, 0.000419989] x = 5.56244e-07
     mag = 0.344807 (should be 0.000745818)

[slembcke]

Eeek. That is nasty, and I do a lot of similar things in Chipmunk. Actually I don't understand how a bug like that could have slipped past their QC... Nearly every graphics program on earth does stuff like that.

I guess I've been using Clang 2.0 from Xcode 4.0.2 as I've not been enthusiastic to upgrade to 10.7 yet. I've heard from a number of people now that Xcode 4.1 has a lot of new bugs, though none with the compiler itself. Clang 3.0 (IIRC) that comes with Xcode 4.2 is supposed to be much better, but then you'd have to be using a beta version of Xcode that is iPhone specific. :-\

Unfortunately if it is a compiler bug there isn't much you can do except use a different compiler to build the lib until they fix it.