Crash In IPhone

When I add too mush Objects(The balls) in iPhone/iPhone simulator,It will crash.Crashes every time.The worst things is I can't get useful stack at that time.Is there a limit of object or something like it ?

You can try it or run my app if you need.Just the ball in example,very simple one.

BTW: sometimes there are solid ball fused,I don't know why.Must be bug of orx or box2d or something.

see the picture for more information.
bug_balls.png

Comments

  • edited May 2010
    The crash happens in Box2D. There's a hardcoded limit on the number of contact pairs you can have in Box2D physics simulation.
    If you run the debug version you'll get an assert from Box2D.
    It's not iPhone specific and will happen on any platforms.

    You can always recompile Box2D with an upgraded limit, but I don't think the iPhone can handle it, performance-wise.

    As for the merged balls, I'd need to get code/data to give a definitive diagnostic, but orx only displays objects at the positions Box2D provides. There might be some tricks in Box2D to prevent this kind of interpenetration, like playing with the iteration number per simulation steps or the bullet flag for dynamic objects.

    I'm no Box2D expert though, so you might get a better feedback from the Box2D community.
  • edited May 2010
    OK,When I know there surely a limit,I can do something prevent it.I just make sure there are not crashes randomly.
    I think I need to find more information from box2d community too.
    Thank you.
  • edited May 2010
    if there is hardcoded limit on the number of contact pairs in box2D,it can't explain this crash now.

    This time,it crashed when there are only two contact with a few balls less than ten.

    Screen_shot_2010_05_27_at_10.png


    Assertion failed: (pair->IsFinal() == false), function AddBufferedPair, file /Users/rom/Workspace/orx/extern/Box2D_2.0.1/Orx/build/Xcode/../../../Source/Collision/b2PairManager.cpp, line 221.
    Program received signal: “SIGABRT”.

    no useful stack info:
    #0 0x967442fa in mach_msg_trap
    #1 0x96744a67 in mach_msg
    #2 0x01f9d382 in CFRunLoopRunSpecific
    #3 0x01f9cc48 in CFRunLoopRunInMode
    #4 0x029357ad in GSEventRunModal
    #5 0x02935872 in GSEventRun
    #6 0x008f5003 in UIApplicationMain
    #7 0x00002db0 in orx_Execute at orx.h:232
    #8 0x00002e1f in main at iOccupy.mm:138
  • edited May 2010
    Could it be a problem in using box2D? Or fix this bug with upgrade box2d to a new version?
  • edited May 2010
    It's definitely a Box2D assert but I've never encountered it so far! :(

    Maybe if you send me your program I can try to see if I see some obvious mistake, otherwise I'm afraid you'll have to ask directly on Box2D's forums.

    I'll update to a newer version of Box2D but probably after 1.2 release as I'm running out of time. I'll let you know as soon as it's done on the svn.
  • edited May 2010
    It's easy to happen when you create balls, my code is almost the same as tutorials with scaling the red ball smaller.

    I think I can wait for your updating box2D and try again.

    Now is it near the time to release orx 1.2?
  • edited May 2010
    I'll try to scale down the balls and try on my side then, as the tutorial never crashed with me and I've spawned hundreds & hundreds of balls. =)

    As for the release, I have two choices: either I do a release next week but OpenGL ES 2.0 won't be supported and the SDL plugins are not 100% ready for PC or I'll delay a bit more but it might even end up end of august as I'll probably have to move first (I signed an offer from another company on the other side of the continent :)).

    As you're already using the svn version, the release wouldn't change much for you anyway.
Sign In or Register to comment.