Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Want more efficiency in your development work? Sign up to receive weekly tech and creative know-how from Unity experts.
    Dismiss Notice
  4. Build games and experiences that can load instantly and without install. Explore the Project Tiny Preview today!
    Dismiss Notice
  5. Nominations have been announced for this years Unity Awards. Celebrate the wonderful projects made by your peers this year and get voting! Vote here!
    Dismiss Notice
  6. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  7. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

physics2d assertion fails in 2018.1

Discussion in 'Physics' started by herb_nice, May 24, 2018.

  1. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    in the editor in 2018.1.0f2 we are noticing a lot of this pattern in the debug output in the editor:


    Assertion failed: PostSolve should not be called for a contact flagged as invalid.
    UnityEngine.Physics2D:Simulate(Single)

    Assertion failed: Assertion failed on expression: 'contactState != Collision2D::ContactInvalid'
    UnityEngine.Physics2D:Simulate(Single)

    Assertion failed: PreSolve should not be called for a contact flagged as invalid.
    UnityEngine.Physics2D:Simulate(Single)


    this is with multithreaded physics ON. we did not notice this in 2017.1.1f1. we have not tested multithreaded physics OFF as thoroughly yet, but will consider it.


    does anyone know the causes and consequences of that particular debug spew? is it dangerous?

    can it be caused by dynamically toggling the simulated flags on rigidbodies when spawning/despawning, for example?
     
  2. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    here is another one that is firing:

    Assertion failed: Assertion failed on expression: 'collision->m_ContactCount >= 0'
    UnityEngine.Physics2D:SyncTransforms()
     
  3. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    and

    Assertion failed: Assertion failed on expression: 'collision->m_ContactCount >= 0'
    UnityEngine.Physics2D:Simulate(Single)

    ^ same message, different callstack
     
  4. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    No reports of that during all of the beta unfortunately. Is this easy to reproduce? Could you produce a bug report and send it to me so I can track it down?

    Dynamically toggling the simulated flags on RB causes their contacts to be destroyed. Maybe depending on when you do this i.e. maybe in a callback it might cause some subtle interaction that hasn't been spotted in MT but nothing off the top of my head comes to mind.
     
  5. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    i'll try to get a repro in that shareable project and send it to you. not sure what behaviour on my end is causing it.
    .
     
  6. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    as for easy to reproduce, seems to take from 1-30 mins or so to repro. added some logging whenever simulation is toggled, and of course now it takes longer...
     
  7. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    also- i looked at code paths and it is possible for simulation to be toggled during callback. and found a case where collider2d.enabled can be toggled during a callback, as motion is still simulated but collision are disabled for that particular object.

    we can defer those state changes if they are determined to be the cause.

    i will add those behaviours to the test project now and start a soak on it.
     
    MelvMay likes this.
  8. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    test app has been soaking, still no hits. in the actual app, i added logging any time a collider is disabled/enabled, or a rigidbody is simulated/not simulated. and also 'tick' once an update (so i can collapse). this burst seems to be unrelated to turning things on and off:

    upload_2018-5-25_20-42-14.png
     
  9. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    ^ that was logging all simulated/collider enabled toggles in callbacks. when logging absolutely everywhere with framecounts, i am seeing this pattern emerge:

    upload_2018-5-25_21-11-49.png

    on frame 1816, a projectile was spawned, and a different projectile was despawned, from update. projectiles are simple, just a rigidbody with a circle collider, which is a trigger.

    then we step physics and it fires some asserts. no enabling/disabling was done in callbacks on that frame.

    disable head collider happens in some code that runs post-physics where health is updated.
     

    Attached Files:

  10. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    to clairfy, "spawned" means rigidbody2d.simulated = true; despawned means false
     
  11. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    this one is interesting, as it's the act of setting .enabled to false that indicates that there is a problem under the hood. still not from a callback though.

    upload_2018-5-25_21-27-0.png
     
  12. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    in appreciation of the ambition of getting some physics spikes off the main thread, here's a summary:

    - this only seems to happen with multithreaded physics ON. so, it's not fatal or anything.
    - most common case appears to happen when setting rigidbody2d.simulated, outside of a callback
    - also seen when setting collider2d.enabled, outside of a callback
    - there appears to be a sometimes side effect glitch of a collisionstay continually firing around the time of those asserts
    - i have not been able to repro in a test app that is purposefully being way meaner to the physics2d engine than the game is. so far it has soaked for more than 4 hours without repro, game gets a repro within 12000 frames. all of the physics2d settings are the same except the actual game has a few more collision layers.

    i will let it soak overnight and if it repros i will submit the test app. otherwise i'll just turn off physics mutlithreading until some future build.
     
  13. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    well, soak test did NOT repro on shareable project. so, no idea. something is definitely wrong, but I am not at liberty to spend any more time chasing it down. disabling multithreaded physics and moving on with my life.
     
  14. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    i sent a bug report. one final note: the state changes during callback i mentioned only happen during a boss or player death which are quite rare.
     
  15. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    Thank you for spending so much time trying to narrow it down. Send me the case number so I can grab it otherwise QA may reject it as non-reproducible.

    From what you've written I'll see if I can isolate something on my end. I'll not be able to do this until later this week but it'll get done.

    I'll post back here whether I find something or not.
     
  16. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    Hey Melv-

    sent you the case info. in 2018.1.3f1 multithreaded physics2d the same asserts fire. will update the report.
     
  17. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
  18. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    I have a super important fix for multi-threaded joints I want to get out ASAP but I'd also like to get a fix for this out with it so will delay that fix while I resolve this one.
     
  19. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    no worries Melv-

    everything seems to be working fine single-threaded so not a blocker here.

    this is one of those bitch-to-repro bugs that prefers to happen when you are not looking for it, so much sympathy in hunting it down.
     
    MelvMay likes this.
  20. HungPark

    HungPark

    Joined:
    Feb 28, 2017
    Posts:
    21
    Hi!, I have a similar problem as Mr. herb_nice's. I try to test Collision between two objects with a Rigidbody 2D and a Box collider 2D. They don't work. They don't collide, but pass through. I did this test with Editor 2018.1.1f1(personal).

    Checking this issue by Unity technicians will be very appreciated.
     
    Last edited: Jun 8, 2018
  21. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    I saw your other post here and you seem to think this is related to playmaker. The problem here isn't related to the behaviour you describe. Are you using the experimental multi-threading?

    If you think you've found a bug then please create a bug report otherwise it's impossible to fix.
     
  22. HungPark

    HungPark

    Joined:
    Feb 28, 2017
    Posts:
    21
    I've never used multi-threading. Anyway, after checking some points, I'll report this issue again.
    Thank you.
     
  23. HungPark

    HungPark

    Joined:
    Feb 28, 2017
    Posts:
    21
    I tried to open "Report a Bug" in the Editor Menu(Help -> Report a Bug), but it does not open.
    Where can I find the second alternative - the Executable in the directory where Unity is installed - to access to Report a Bug directly?


    Thanks.
     
    Last edited: Jun 10, 2018
  24. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    Your issue then is nothing to do with what is being discussed here which is to do with the experimental multi-threading only.

    Sounds like you have an installation error (try reinstalling Unity again) but that's something you should discuss on your original thread please and not here.
     
  25. HungPark

    HungPark

    Joined:
    Feb 28, 2017
    Posts:
    21
    Very sorry. I downloaded Unity2018.1.3f1 newly, and Report a Bug menu opened. I'll create a bug report by your instruction. Thank you very much.

    I have solved this issue.

    I changed Unity Editor into New Version after completing programming, so this might bring this fluctuation.

    Thank you Mr. MelvMay.
     
    Last edited: Jun 17, 2018
  26. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    we are still seeing these asserts if multithreaded physics 2d is turned on in unity 2018.1.6f1. so, it stays off.
     
    Last edited: Jul 2, 2018
  27. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    I believe we've identified what the issue was here and we're currently doing some QA on the fix which is being bundled with other various multi-threaded fixes/improvement. I'll update you here when it has landed.
     
    herb_nice likes this.
  28. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    I was wondering if you'd have time to check to see if this problem still reproduces in 2018.3 beta or in 2018.2.
     
  29. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    Hey Melv- it reproduced as far as the newest we have tried, which is 2018.2.8f1. We are back on 2018.1.9f1 as 2018.2.x allocates 80 bytes of GC memory every frame in the RenderPipelineManager.CleanupRenderPipeline().
     
  30. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    * adding information to the endless "what version of unity is the best to use" saga, 2018.1.9f1 crashes on boot in vulkan code on some modern androids, so we also had to disable vulkan. this probably won't work for everyone...

    i have been watching the release notes and haven't seen anything that read like a fix for the multithreaded physics 2d contacts errors that this thread is about. did you submit a fix? is there a build in particular that you would like soaked?
     
  31. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    Because the issue you saw was so hard to reproduce it's not easy to find a direct problem that causes it however there have been a number of race-condition / memory stomping issues that have been resolved. I recently fixed one that isn't in the 2018.3 beta yet but I was wondering if the other fixes that are in 2018.3 beta resolve your issue. I believe one of the fixes was in 2018.2 but 2018.3 beta contain all the fixes minus one so far. I can get more specific than that in the morning for you.
     
  32. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    i read that as "could you please try the 2018.3.beta?" I'll see if we can give it a soak soon.
     
  33. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    In short, yes. :)

    If that doesn't fix our issue I'll let you know when the follow-on fix is backported to 2018.3 beta as that might solve your problem.
     
  34. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    ok, that was fast. on 2018.3.0b2, we saw the following when running multithreaded physics2d ON:

    upload_2018-9-24_13-17-35.png

    the editor then crashed when we stopped playback.
    the stack trace from the crash was as follows:


    ========== OUTPUTTING STACK TRACE ==================

    0x0000000141C01A01 (Unity) PhysicsContacts2D::DestroyContacts
    0x0000000141C009AC (Unity) Collider2D::Cleanup
    0x0000000141C0156B (Unity) Collider2D::Deactivate
    0x00000001405AF82F (Unity) GameObject::ActivateAwakeRecursivelyInternal
    0x00000001405AF602 (Unity) GameObject::ActivateAwakeRecursivelyInternal
    0x00000001405AF602 (Unity) GameObject::ActivateAwakeRecursivelyInternal
    0x00000001405AF602 (Unity) GameObject::ActivateAwakeRecursivelyInternal
    0x00000001405AF602 (Unity) GameObject::ActivateAwakeRecursivelyInternal
    0x00000001405AF602 (Unity) GameObject::ActivateAwakeRecursivelyInternal
    0x00000001405AF602 (Unity) GameObject::ActivateAwakeRecursivelyInternal
    0x00000001405AF362 (Unity) GameObject::ActivateAwakeRecursively
    0x00000001405B14A3 (Unity) GameObject::Deactivate
    0x00000001408ED760 (Unity) DestroyObjectHighLevel
    0x0000000140971A14 (Unity) DestroyWorldObjects
    0x0000000140E50CB6 (Unity) EditorSceneManager::RestoreSceneBackups
    0x000000014130B7C8 (Unity) PlayerLoopController::ExitPlayMode
    0x000000014131715F (Unity) PlayerLoopController::SetIsPlaying
    0x000000014131A192 (Unity) Application::TickTimer
    0x00000001414746FB (Unity) MainMessageLoop
    0x0000000141476396 (Unity) WinMain
    0x000000014243F25A (Unity) __scrt_common_main_seh
    0x00007FFBB16C3034 (KERNEL32) BaseThreadInitThunk
    0x00007FFBB1A51461 (ntdll) RtlUserThreadStart


    as for "Cannot set the connected rigidbody for the 'SpringJoint2D' type because it connects to a rigidbody in a different physics scene.", that first item in the screenshot is NEW. that was not in 2018.2.8f1. the line of code that caused that error was:

    mySpringJoint.connectedBody = validRigidbody; // this rigidbody is a valid rigidbody currently enabled and active

    and, the springs were behaving as if they had been passed null. they were aiming for 0,0 in the world.

    good luck!
     
  35. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    I sent the crash report, put your name in the description so a log and crash dump should be on your way.

    I did not write a bug about the spring issue, would you like one? that happens with or without multithreaded physics 2d on in 2018.3.0b2.
     
  36. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    > Cannot set the connected rigidbody for the 'SpringJoint2D'
    This was a multi-scene issue that affected a bunch of things including 2D joints but that has been fixed and is on its way to 2018.3 beta soon.
     
  37. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    > 0x0000000141C01A01 (Unity) PhysicsContacts2D::DestroyContacts
    0x0000000141C009AC (Unity) Collider2D::Cleanup
    I believe this is also one that has been fixed but hasn't yet landed in 2018,3 beta.

    Might be best for me to contact you again as soon as the fixes land there. Thanks for checking!
     
  38. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    You got it Melv! good luck and let me know when you have something that needs a soak. :D
     
  39. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    Just checking but is this using the project attached to case 1042478? I only ask because I've let that run on 2018.3.0b2 for a fair while and get no errors on several machines.
     
  40. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    Good news! I've just had a case submitted that reproduces your issue but in super short time. This is exactly what I needed to narrow it down. I'll update you when I have something useful to report.
     
  41. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    So the new case reproduces the problem really quickly and puts out the same errors as you were seeing. The good news is that this allowed me to narrow down exactly what was causing it. Turns out it's nothing to do with the multi-threaded simulation itself but the contact reporting which was also multi-threaded at the same time.

    Frustratingly the problem was a simply array index in a job using the wrong index.
    Code (CSharp):
    1.  
    2. - Collision2D::Manifold& manifold = collision->m_Manifolds[i];
    3. + Collision2D::Manifold& manifold = collision->m_Manifolds[manifoldIndex];
    I'll get this change into a backport ASAP.
     
    herb_nice likes this.
  42. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    A bunch of fixes just landed internally in 2018.2.12f1 and 2018.3.0b5 so keep an eye out for those and let me know if it fixes your issue.

    Release Note:
    Case 1042478 - Fix contact callback assertion errors when using multi-threaded 2D physics.
     
    herb_nice likes this.
  43. dualpulse

    dualpulse

    Joined:
    Jul 7, 2013
    Posts:
    2
    Hello herb and Melv, thankyou both for your work in chasing down these issues - our project is also urgently awaiting a fix for the following issue:

    "Cannot set the connected rigidbody for the 'SpringJoint2D' type because it connects to a rigidbody in a different physics scene."

    - we will keep an eye out for 2018.3.0b5 and let you know how we go.
     
  44. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,530
    That issue only appeared in the alpha/beta of 2018.3. I would suggest you not base an urgent project on an alpha/beta. Anyway, it has been fixed and will be in that release you mentioned with the following release note:

    "Case 1080424 - Fixed erroneous multi-scene console warning when trying to connect to a disabled Joint2D."
     
  45. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    initial soaking 2018.2.12f1 has not shown the above mentioned multithreaded physics2d asserts and warnings. I will report if deeper soaking shows any weirdness.

    it is nice to see the island solver running on a different core, however, rendering in 2018.2.x still allocates 40-80 bytes of garbage every frame, making this version of unity fairly invalid for us. this is in addition to the annoying GC thrash from collision callbacks. large GC frame blocks are visible, frequent and obvious making smooth performance not very possible. we are blaming the increased GC thrash for this- it's much worse than 2018.1.x.

    seems like the only thing you can do to deal with GC thrash is call Sytem.GC.Collect() periodically when you are ok with blocking for 20+ms and dropping a frame or 2- how does this work for VR? how does this sort of performance degradation make it past QA 12 releases in a row?
    upload_2018-10-12_12-3-29.png
    upload_2018-10-12_12-2-10.png

    the rendering woes belong in another thread- but full picture, we are now weighing the slight physics performance increase against the GC performance degradation in 2018.2.x. I'm still recommending 2018.1.9f1 until all the numbers are in.
     
  46. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    98
    7 hour soak of 2018.2.12f1 shows 0 instances of the initial problem. other issues aside*, multithreaded physics2d appears to be usable now.


    * in addition to the GC.Collect() we already call on screen transitions and boss deaths to suck up the garbage from collision callbacks in order to prevent the gc block of doom from happening during gameplay, we tried adding a GC.Collect() on a variety of timers to suck up the new garbage spew from 2018.2.x render pipeline. this ward does prevent the gc frame of doom, but causes regular blocks of 10-20ms, which really means a dropped frame at a regular interval. not cool. for now it looks like we're sticking with 2018.1.9f1, multithreaded off.
     
    Last edited: Oct 13, 2018