Hitting segfault...

Discuss any Chipmunk bugs here.
Post Reply
snichols
Posts: 53
Joined: Mon Nov 12, 2012 9:20 pm
Contact:

Hitting segfault...

Post by snichols »

I've been running into an occasional crash in my most recent project. The crash is at line 66 of cpSpaceComponent.cpp.

Code: Select all

// Update the arbiter's state
arb->stamp = space->stamp;
arb->handler = cpSpaceLookupHandler(space, a->collision_type, b->collision_type);
cpArrayPush(space->arbiters, arb);
				
cpfree(contacts); /* CRASH */
It looks like "contacts" was already freed by the library. I know this because my heap library has no knowledge of the pointer being passed in. And the pointer seems to be valid (non-null).

Can you think of any cause for this?
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Hitting segfault...

Post by slembcke »

Hrm. So that happens when a sleeping body is woken up. The storage for active contacts is usually managed in large buffers by the space for performance reasons. The only way it could be freeing a bad pointer there is if cpSpaceActivateBody() was called on a non-sleeping body. It's only called from a single place, and there is an assertion to check for non-sleeping bodies. If you are disabling assertions with NDEBUG, try leaving them in. Beyond that I have no idea. The regular stdlib free() would log warnings if I was freeing bad pointers, and that code hasn't changed in a couple years.

Since you are supplying your own memory functions I'd add a bit of logging to them. It's a pain to dig through the logs, but it's helped me track down a few bugs in the past.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
snichols
Posts: 53
Joined: Mon Nov 12, 2012 9:20 pm
Contact:

Re: Hitting segfault...

Post by snichols »

I definitely have asserts on. This is a full debug build.

Here's another error I'm hitting when trying to get a reproduction case. Perhaps this might shed some light on how things are going wrong (odd behavior like this is oftentimes related):

"Aborting due to Chipmunk error: This addition/removal cannot be done safely during a call to cpSpaceStep() or during a query. Put these calls into a post-step callback."

This seems to be caused during a call to cpSpaceRemoveShape. The cpAssertSpaceUnlocked call is failing. The space pointer seems to be okay, but the lock variable is set to 2. This seems to be possible only if I'm reentering the library. My callstack does not show that I'm reentering the library.

Here's my stack:

Code: Select all

_abort()  + 0x83 bytes	
cpMessage(const char * condition, const char * file, int line, int isError, int isHardError, const char * message, ...)  Line 49
cpSpaceRemoveShape(cpSpace * space, cpShape * shape)  Line 370 + 0x29 bytes	
AnimatedPhysicsObject::RemoveShapeFromSpace(cpShape * TheShape, cpSpace * TheSpace)  Line 196 + 0xd bytes	
AnimatedPhysicsObject::OnRemoveFromPhysicsLayer()  Line 179	
PhysicsLayer::InternalRemoveObject(PhysicsObject * TheObject)  Line 225 + 0xf bytes	
PhysicsLayer::RemoveObject(PhysicsObject * TheObject)  Line 214	
PhysicsLayer::InternalRecycleObjects()  Line 180	
PhysicsLayer::Update()  Line 157	
UpdateManager<SceneObject2D>::Update()  Line 152 + 0x13 bytes	
SceneLayer2D::Update()  Line 82	
GameLevel::Update()  Line 295	
UpdateManager<SceneObject2D>::Update()  Line 152 + 0x13 bytes	
SceneLayer2D::Update()  Line 82	
UpdateManager<SceneObject2D>::Update()  Line 152 + 0x13 bytes	
SceneLayer2D::Update()  Line 82	
UpdateManager<SceneObject2D>::Update()  Line 152 + 0x13 bytes	
SceneLayer2D::Update()  Line 82	
UpdateManager<SceneObject2D>::Update()  Line 152 + 0x13 bytes	
SceneGraph2D::Update()  Line 53	
Rage::Update()  Line 88 + 0x15 bytes	
Game::Update()  Line 52	
main(int argc, const char * * argv)  Line 342 + 0x15
Here's my space watch dump:

Code: Select all

space	0x0ad84038 {iterations=0x0000000a gravity={...} damping=0.94999999999999996 ...}
iterations	0x0000000a
gravity	{x=0.00000000000000000 y=400.00000000000000 }
damping	0.94999999999999996
idleSpeedThreshold	0.00000000000000000
sleepTimeThreshold	1.0000000000000000
collisionSlop	0.10000000149011612
collisionBias	0.0017970074436457143
collisionPersistence	0x00000003
enableContactGraph	0x00000000
data	0x0ad7d830
staticBody	0x0ad840f0 {velocity_func=0x064ecba8 position_func=0x064e6320 m=1.#INF000000000000 ...}
stamp	0x0000e4c4
curr_dt	0.0083007812500000000
bodies	0x0ad5fe60 {num=0x0000002f max=0x00000100 arr=0x0b02efd0 }
rousedBodies	0x0ad60808 {num=0x00000000 max=0x00000040 arr=0x0b0e0be8 }
sleepingComponents	0x0ad602f8 {num=0x000000a7 max=0x00000100 arr=0x0b018f18 }
staticShapes	0x0ad44d40 {klass=0x06e1e570 bbfunc=0x067b3de0 staticIndex=0x00000000 ...}
activeShapes	0x0ad44f00 {klass=0x06e1e570 bbfunc=0x067b3de0 staticIndex=0x0ad44d40 ...}
arbiters	0x0ad60910 {num=0x00000022 max=0x00000100 arr=0x0b02ebc8 }
contactBuffersHead	0x0ae76210 {stamp=0x0000e4c4 next=0x0b026c30 numContacts=0x0000002c }
cachedArbiters	0x0ad83bf8 {entries=0x00000025 size=0x00000185 eql=0x067b3e10 ...}
pooledArbiters	0x0ad42970 {num=0x000001cf max=0x00000200 arr=0x0ae75a08 }
constraints	0x0ad54e90 {num=0x00000000 max=0x00000010 arr=0x0adfae48 }
allocatedBuffers	0x0ad5fa78 {num=0x0000000a max=0x00000010 arr=0x0afaea98 }
locked	0x00000002
collisionHandlers	0x0ad65b28 {entries=0x0000000c size=0x0000000d eql=0x067b3ea0 ...}
defaultHandler	{a=0x00000000 b=0x00000000 begin=0x067b3aa0 ...}
skipPostStep	0x00000000
postStepCallbacks	0x0ad30410 {num=0x00000000 max=0x00000004 arr=0x0ad47808 }
_staticBody	{velocity_func=0x064ecba8 position_func=0x064e6320 m=1.#INF000000000000 ...}
Sorry for the massive dump. :) Can you think of any way this could be occurring?

steve
snichols
Posts: 53
Joined: Mon Nov 12, 2012 9:20 pm
Contact:

Re: Hitting segfault...

Post by snichols »

You'll be happy to know that this looks to be caused by some memory corruption on my end. At least that's what it's looking like... more info to come if needed.
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: Hitting segfault...

Post by slembcke »

Hmm. So I was going to say that the only time I've actually heard of the space lock getting unbalanced was due to exception handling. An exception was thrown inside of a Chipmunk callback, and then caught and discarded in the main run loop. There were a couple people that did that unknowingly because of how the framework they were using worked.

The other possibility is of course memory corruption, but that usually isn't so consistent.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
snichols
Posts: 53
Joined: Mon Nov 12, 2012 9:20 pm
Contact:

Re: Hitting segfault...

Post by snichols »

Good point about the exception issue. I do believe my memory corruption was causing exceptions to be thrown in callbacks. I'll make sure all my callbacks have proper try/catch implementation.

Thanks!

steve
Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests