Chipmunk breaking, but only on one platform
Posted: Sat Mar 19, 2011 4:15 am
So here's one. I am porting my code to Android. As soon as I run on Android, Chipmunk (it's 3.5.4) breaks. It gets as far as trying to add an object to a space, then freaks out. There are two possibilities here--
1. My Android code runs through different initialization code from my other compile targets, then hands control over to a common program_init function that sets up chipmunk. Maybe I did something in the initialization that breaks things for Chipmunk later.
2. Somehow Chipmunk behaves different on Android.
(1) seems more likely, but either way, the code is failing in a very odd way.
Here's what happens. I have some simple code which in its early stages is actually fairly similar to the old "MoonBuggy" demo. Loosely, it
- cpInitChipmunks
- creates a couple of spaces
- Creates, then adds to one of the spaces, four cpSegmentShapes
I'm finding that the code gets as far as the first cpSpaceAddStaticShape, but never exits that function.
Inside cpSpaceAddStaticShape, it's getting as far as cpSpaceActivateShapesTouchingShape, wherein it does a cpSpaceShapeQuery to look for any objects that need to be woken up by the newly inserted object. As soon as cpSpaceHashQuery is called for the first time (on the active hash), disaster strikes because, for some reason, the cpBB chipmunk decides to test for the shape is totally invalid. I added a
to the start of cpSpaceHashQuery, and on Android it prints out:
As a unpleasant coincidence would have it, this particular combination of bad values causes cpSpaceHashQuery to go into an infinite loop-- reason why, floor_int at least in the Android emulator winds up converting all those bad values to INT_MAX. Because r is thus equal to INT_MAX, the i<=r condition below can never be true, i just wraps around forever.
(A note, unrelated to the actual problem: You might want to consider doing a cpAssert(isfinite(bb.l) && ... ) in this function, or at the end of cpShapeCacheBB or in some similar places? You might also want to consider adding a quick check-and-bail-out for r==INT_MAX before performing the loop because even without having actually invalid floats a user could believably hit the infinite-loop condition simply by having a coordinate which is extremely large. Though I think at that point they likely would have other problems...)
ANYWAY when I run this same code on OS X it prints out
I feel a little stuck on figuring out how the two versions diverge because I don't think I understand where the cpBB in cpSpaceShapeQuery (obtained by calling cpShapeCacheBB) is coming from.
Have you seen anything like this before? Why do you suppose I am winding up with this invalid BB on Android only? Is there some further testing I could do?
Thanks!
1. My Android code runs through different initialization code from my other compile targets, then hands control over to a common program_init function that sets up chipmunk. Maybe I did something in the initialization that breaks things for Chipmunk later.
2. Somehow Chipmunk behaves different on Android.
(1) seems more likely, but either way, the code is failing in a very odd way.
Here's what happens. I have some simple code which in its early stages is actually fairly similar to the old "MoonBuggy" demo. Loosely, it
- cpInitChipmunks
- creates a couple of spaces
- Creates, then adds to one of the spaces, four cpSegmentShapes
I'm finding that the code gets as far as the first cpSpaceAddStaticShape, but never exits that function.
Inside cpSpaceAddStaticShape, it's getting as far as cpSpaceActivateShapesTouchingShape, wherein it does a cpSpaceShapeQuery to look for any objects that need to be woken up by the newly inserted object. As soon as cpSpaceHashQuery is called for the first time (on the active hash), disaster strikes because, for some reason, the cpBB chipmunk decides to test for the shape is totally invalid. I added a
Code: Select all
ERR("bb lrbt %lf %lf %lf %lf; dim %lf", (double)bb.l, (double)bb.r, (double)bb.b, (double)bb.t, (double)dim);
Code: Select all
03-18 22:24:21.332: ERROR/Jumpcore(517): bb lrbt -Inf -Inf NaN NaN; dim 0.100000
(A note, unrelated to the actual problem: You might want to consider doing a cpAssert(isfinite(bb.l) && ... ) in this function, or at the end of cpShapeCacheBB or in some similar places? You might also want to consider adding a quick check-and-bail-out for r==INT_MAX before performing the loop because even without having actually invalid floats a user could believably hit the infinite-loop condition simply by having a coordinate which is extremely large. Though I think at that point they likely would have other problems...)
ANYWAY when I run this same code on OS X it prints out
Code: Select all
bb lrbt -1.700000 -1.500000 -1.100000 1.100000; dim 0.100000
Have you seen anything like this before? Why do you suppose I am winding up with this invalid BB on Android only? Is there some further testing I could do?
Thanks!