Hitting segfault...

Discuss any Chipmunk bugs here.

Hitting segfault...

Postby snichols » Wed Dec 05, 2012 5:55 pm

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?
snichols
 
Posts: 53
Joined: Mon Nov 12, 2012 9:20 pm

Re: Hitting segfault...

Postby slembcke » Wed Dec 05, 2012 6:44 pm

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/
User avatar
slembcke
Site Admin
 
Posts: 4164
Joined: Tue Aug 14, 2007 7:13 pm

Re: Hitting segfault...

Postby snichols » Wed Dec 05, 2012 7:53 pm

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

Re: Hitting segfault...

Postby snichols » Thu Dec 06, 2012 1:27 am

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.
snichols
 
Posts: 53
Joined: Mon Nov 12, 2012 9:20 pm

Re: Hitting segfault...

Postby slembcke » Thu Dec 06, 2012 1:52 pm

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/
User avatar
slembcke
Site Admin
 
Posts: 4164
Joined: Tue Aug 14, 2007 7:13 pm

Re: Hitting segfault...

Postby snichols » Thu Dec 06, 2012 2:15 pm

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
snichols
 
Posts: 53
Joined: Mon Nov 12, 2012 9:20 pm


Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest

cron