Problem when upgrading

Official forum for the Chipmunk2D Physics Library.
ganesha
Posts: 71
Joined: Mon Sep 06, 2010 1:29 pm
Contact:

Problem when upgrading

Post by ganesha »

I have upgraded an old project to the latest 6.1.2 pro version. But I get some weird errors when running my code.

Trace:

cpBodyIsRogue at cpBody.h:152:
0x1789bd: cmpl $0, 92(%eax)
cpBodyActivate at cpSpaceComponent.c:138:
0x178c17: cmpl $0, %eax
cpSpaceAddConstraint at cpSpace.c:305:
0x1776d4: movl -16(%ebp), %eax
[ChipmunkConstraint addToSpace:] at ChipmunkConstraint.m:71:
0x14fb1b: movl %eax, -20(%ebp)

Code:

Code: Select all

MyChipmunkObject *newObject = [[MyChipmunkObject alloc] initWithTypeAndPosition:type position:position size: CGSizeMake(20, 20) ];
[self addObjectToSpace: newObject];

Code: Select all

-(void) addObjectToSpace: (id) object {	
    @synchronized(self.space){
        [self.space add:object];
    }
}
I have also tried addPostStepCallback and smartAdd with similar results. I had to make some small changes, e.g. flattenobjects to an NSArray etc.
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Problem when upgrading

Post by slembcke »

Are you trying to add a constraint attached to a null body to your space? That looks to be the cause to me.

At some point in the past, it was an undocumented "feature" that a null bodies were promoted to a static bodies. Maybe you were unknowingly taking advantage of that? With Objective-Chipmunk, you can simply create do [ChipmunkBody staticBody] to create a new static body, then assign it to something and forget about it. Objective-C will clean up the memory for you when it's done.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
ganesha
Posts: 71
Joined: Mon Sep 06, 2010 1:29 pm
Contact:

Re: Problem when upgrading

Post by ganesha »

Yes, that was the problem.

Code: Select all

bodyB: nil
Thanks!
ganesha
Posts: 71
Joined: Mon Sep 06, 2010 1:29 pm
Contact:

Re: Problem when upgrading

Post by ganesha »

Just another question. I use the new ChipmunkHastySpace and objects freeze and pass the floor etc. It is very likely my old code but what is the best practice of adding objects to the space?

addPostStepCallback
add
smartAdd

What about synchronization?
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Problem when upgrading

Post by slembcke »

Hmm. It happens with a hasty space but not with a regular space? With or without threads enabled?

So add: does a regular cpSpaceAdd*() call. It will throw an error if you attempt to do so inside of a collision callback or such. To do that, you need to schedule a post-step callback using the object to add as the key which will call your code right before the controlling cpSpace function returns (cpSpaceStep(), cpSpaceQuery*(), etc.). smartAdd: calls add: if you aren't in a callback, and schedules a post-step callback to do it if you are. Using smartAdd: all the time is a decent best practice, unless you are certain that you don't want a post-step callback scheduled. It's more relevant with smartRemove: where you know that using the object to be removed as a key will interfere with another post-step callback.

More in the docs: http://chipmunk-physics.net/release/Chi ... space.html
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
ganesha
Posts: 71
Joined: Mon Sep 06, 2010 1:29 pm
Contact:

Re: Problem when upgrading

Post by ganesha »

I use the ChipmunkHastySpace with no changes.

I can't really debug because the problem is so rare. So I print out the properties of all added objects and check if they are added to the space or not. I looks normal in this respect.

The problem is hard to grasp and replicate. The best setup to replicate it is to have a static body. On that body I add a chipmunk object. Cube A. I add another cube B inside the static object and it moves up into the previous cube without any collision. If I add a third cube it will collide with both the first and second cube.

I added a special check in my CollisionHandler:

Code: Select all

		if(object1.type == CUBE && object2.type == CUBE){
			NSLog(@"CUBE COLLISION");
			return YES;
		}
The first two objects A and B doesn't collide with each other. But with all other objects. They can share the same space and if I delete A, all other cubes will interact normally with B.

The problem probably hasn't anything to do with the static body. It can be replicated by just adding objects on top of each other but it takes a random number of objects to make it fail or a massive burst of added objects in the same region in space.

The cubes are made in a factory class and share creation process with more complex objects. I wonder if this has anything to do with it. They are added by using the following method:

Code: Select all

    @synchronized(self.space){
        id obj = [self.space smartAdd:object];
}
Attachments
cube.png
cube.png (12.25 KiB) Viewed 9276 times
ganesha
Posts: 71
Joined: Mon Sep 06, 2010 1:29 pm
Contact:

Re: Problem when upgrading

Post by ganesha »

Any ideas about this problem?
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Problem when upgrading

Post by slembcke »

Oh, sorry. I must have missed this. :-\

I don't know of any bugs in the cpHastySpace solver that could cause that to happen. Solver bugs generally simply cause things to explode. Just to be sure though, try forcing it to use a regular space instead of a hasty space.

Code: Select all

// Instead of this:
ChipmunkSpace *space = [[ChipmunkSpace alloc] init];

// Do this:
ChipmunkSpace *space = [[ChipmunkSpace alloc] initWithSpace:cpSpaceNew()];
// NOTE: This will give you a warning that you can safely ignore (or you can declare the method somewhere).
I see that you are also using threads... I wonder if there is any sort of race condition that you might be triggering while creating the objects. Is it easy to disable threading temporarily in your game? That might also be a good place to start.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
ganesha
Posts: 71
Joined: Mon Sep 06, 2010 1:29 pm
Contact:

Re: Problem when upgrading

Post by ganesha »

I see that you are also using threads... I wonder if there is any sort of race condition that you might be triggering while creating the objects.
This is my main suspicion as well. New objects are added by user input so I have tried a new setup to take away that element. I put the creation of the "cube" objects as a timed 0.5 sec event in the main loop.

Quasi-code displaylink:

Code: Select all

- (void)update {
	 cpFloat dt = self.displayLink.duration*self.displayLink.frameInterval;
        if(accTime > 0.5f){
          [self.space smartAdd: [self createCube]];
          accTime = 0;
           ...
        }
        [self.space step:dt];
}
I have also tried using Cocos2d directly:

Code: Select all

- (void)update:(ccTime) dt{
  // create fixed_dt
  [self updateMethod: fixed_dt]
}

- (void)updateMethod:(ccTime) fixed_dt {
        if(accTime > 0.5f){
          [self.space smartAdd: [self createCube]];
          accTime = 0;
         ...
        }
        [self.space step:dt];
}
I have also tried the following changes:
• Different loop modes, e.g. NSRunLoopCommonModes.
• Cut down the update code to a minimum to make sure it can be executed in the given time.
• Tried [[ChipmunkSpace alloc] initWithSpace:cpSpaceNew()];.
• Removed all custom collision handlers.


But sadly all of these combinations can re-create the problem.
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Problem when upgrading

Post by slembcke »

Hmm. I guess that makes a lot more questions. In all of those cases you are still creating the objects on a separate thread though? How many threads do you use? Are you creating separate threads for each object created? What exactly are the threads for?

There is really only one global shared variable in Chipmunk, cpShapeIDCounter. While it would affect determinism in a threaded environment if you wanted to do perfect replays, it shouldn't be an error for multiple shapes to have the same hashid.

What happens if you disable your use of threads entirely or is that not easily possible?
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
Post Reply

Who is online

Users browsing this forum: No registered users and 8 guests