Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Bug / Crash  100% reproducible crash in Oni::RawPinConstraintBatch::EvaluateConstraint
#1
Hello,
I'm facing 100% reproducible crash in the latest Unity 2019.3.0f6 on Enter Play Mode. Here is the stack trace:

Code:
#0  0x0000014b2c3a27 in Oni::RawPinConstraintBatch::EvaluateConstraint(Oni::BatchedConstraintGroup<Oni::PinConstraintData>*, int, int, float)
#1  0x0000014b2f854b in std::__1::__function::__func<Oni::ConstraintBatch<Oni::AerodynamicConstraintData>::EvaluateJacobi(Oni::BatchedConstraintGroup<Oni::AerodynamicConstraintData>*, float)::'lambda'(std::__1::pair<int, int>), std::__1::allocator<Oni::ConstraintBatch<Oni::AerodynamicConstraintData>::EvaluateJacobi(Oni::BatchedConstraintGroup<Oni::AerodynamicConstraintData>*, float)::'lambda'(std::__1::pair<int, int>)>, void (std::__1::pair<int, int>)>::operator()(std::__1::pair<int, int>&&)
#2  0x0000014b2c1e38 in Oni::ParallelTask::Perform()
#3  0x0000014b2d0a38 in Oni::TaskManager::DoTask()
#4  0x0000014b2e6020 in Complete
#5  0x00000174596832 in  (wrapper managed-to-native) Oni:Complete (intptr) {0x7f83d8b931d8} + 0xb2 (0x174596780 0x1745968d9) [0x1582a5c80 - Unity Child Domain]
#6  0x00000174590f5b in  Obi.ObiFixedUpdater:FixedUpdate () {0x7f83eed88df8} + 0x25b (0x174590d00 0x174591191) [0x1582a5c80 - Unity Child Domain]
#7  0x0000013704ee38 in mono_jit_runtime_invoke
#8  0x0000013721142d in do_runtime_invoke
#9  0x0000013721138b in mono_runtime_invoke
#10 0x0000010c8ab507 in scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)
#11 0x0000010c8a50cf in ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)
#12 0x0000010c85ced0 in MonoBehaviour::CallMethodIfAvailable(int)
#13 0x0000010c85cd07 in MonoBehaviour::CallUpdateMethod(int)
#14 0x0000010bd7372b in void BaseBehaviourManager::CommonUpdate<FixedBehaviourManager>()
#15 0x0000010bd7347d in FixedBehaviourManager::Update()
#16 0x0000010c22a994 in InitPlayerLoopCallbacks()::FixedUpdateScriptRunBehaviourFixedUpdateRegistrator::Forward()
#17 0x0000010c21892e in ExecutePlayerLoop(NativePlayerLoopSystem*)
#18 0x0000010c21899a in ExecutePlayerLoop(NativePlayerLoopSystem*)
#19 0x0000010c218c34 in PlayerLoop()
#20 0x0000010a039c31 in PlayerLoopController::UpdateScene(bool)
#21 0x0000010a02b647 in PlayerLoopController::UpdateSceneIfNeeded()
#22 0x0000010a02827c in Application::TickTimer()
#23 0x0000010d99acd5 in -[EditorApplication TickTimer]
#24 0x007fff534db7cb in __NSFireTimer
#25 0x007fff5124c810 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
#26 0x007fff5124c3bc in __CFRunLoopDoTimer
#27 0x007fff5124bf02 in __CFRunLoopDoTimers
#28 0x007fff5122d112 in __CFRunLoopRun
#29 0x007fff5122c66e in CFRunLoopRunSpecific
#30 0x007fff5048b1ab in RunCurrentEventLoopInMode
#31 0x007fff5048aee5 in ReceiveNextEventCommon
#32 0x007fff5048ac76 in _BlockUntilNextEventMatchingListInModeWithFilter
#33 0x007fff4e82277d in _DPSNextEvent
#34 0x007fff4e82146b in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
#35 0x007fff4e81b588 in -[NSApplication run]
#36 0x007fff4e80aac8 in NSApplicationMain
#37 0x0000010d9dc4bf in EditorMain(int, char const**)
#38 0x0000010d9dc7c9 in main
#39 0x007fff7d18f3d5 in start
Reply
#2
(29-01-2020, 10:50 AM)iliakot Wrote: Hello,
I'm facing 100% reproducible crash in the latest Unity 2019.3.0f6 on Enter Play Mode. Here is the stack trace:

Code:
#0  0x0000014b2c3a27 in Oni::RawPinConstraintBatch::EvaluateConstraint(Oni::BatchedConstraintGroup<Oni::PinConstraintData>*, int, int, float)
#1  0x0000014b2f854b in std::__1::__function::__func<Oni::ConstraintBatch<Oni::AerodynamicConstraintData>::EvaluateJacobi(Oni::BatchedConstraintGroup<Oni::AerodynamicConstraintData>*, float)::'lambda'(std::__1::pair<int, int>), std::__1::allocator<Oni::ConstraintBatch<Oni::AerodynamicConstraintData>::EvaluateJacobi(Oni::BatchedConstraintGroup<Oni::AerodynamicConstraintData>*, float)::'lambda'(std::__1::pair<int, int>)>, void (std::__1::pair<int, int>)>::operator()(std::__1::pair<int, int>&&)
#2  0x0000014b2c1e38 in Oni::ParallelTask::Perform()
#3  0x0000014b2d0a38 in Oni::TaskManager::DoTask()
#4  0x0000014b2e6020 in Complete
#5  0x00000174596832 in  (wrapper managed-to-native) Oni:Complete (intptr) {0x7f83d8b931d8} + 0xb2 (0x174596780 0x1745968d9) [0x1582a5c80 - Unity Child Domain]
#6  0x00000174590f5b in  Obi.ObiFixedUpdater:FixedUpdate () {0x7f83eed88df8} + 0x25b (0x174590d00 0x174591191) [0x1582a5c80 - Unity Child Domain]
#7  0x0000013704ee38 in mono_jit_runtime_invoke
#8  0x0000013721142d in do_runtime_invoke
#9  0x0000013721138b in mono_runtime_invoke
#10 0x0000010c8ab507 in scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)
#11 0x0000010c8a50cf in ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)
#12 0x0000010c85ced0 in MonoBehaviour::CallMethodIfAvailable(int)
#13 0x0000010c85cd07 in MonoBehaviour::CallUpdateMethod(int)
#14 0x0000010bd7372b in void BaseBehaviourManager::CommonUpdate<FixedBehaviourManager>()
#15 0x0000010bd7347d in FixedBehaviourManager::Update()
#16 0x0000010c22a994 in InitPlayerLoopCallbacks()::FixedUpdateScriptRunBehaviourFixedUpdateRegistrator::Forward()
#17 0x0000010c21892e in ExecutePlayerLoop(NativePlayerLoopSystem*)
#18 0x0000010c21899a in ExecutePlayerLoop(NativePlayerLoopSystem*)
#19 0x0000010c218c34 in PlayerLoop()
#20 0x0000010a039c31 in PlayerLoopController::UpdateScene(bool)
#21 0x0000010a02b647 in PlayerLoopController::UpdateSceneIfNeeded()
#22 0x0000010a02827c in Application::TickTimer()
#23 0x0000010d99acd5 in -[EditorApplication TickTimer]
#24 0x007fff534db7cb in __NSFireTimer
#25 0x007fff5124c810 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
#26 0x007fff5124c3bc in __CFRunLoopDoTimer
#27 0x007fff5124bf02 in __CFRunLoopDoTimers
#28 0x007fff5122d112 in __CFRunLoopRun
#29 0x007fff5122c66e in CFRunLoopRunSpecific
#30 0x007fff5048b1ab in RunCurrentEventLoopInMode
#31 0x007fff5048aee5 in ReceiveNextEventCommon
#32 0x007fff5048ac76 in _BlockUntilNextEventMatchingListInModeWithFilter
#33 0x007fff4e82277d in _DPSNextEvent
#34 0x007fff4e82146b in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
#35 0x007fff4e81b588 in -[NSApplication run]
#36 0x007fff4e80aac8 in NSApplicationMain
#37 0x0000010d9dc4bf in EditorMain(int, char const**)
#38 0x0000010d9dc7c9 in main
#39 0x007fff7d18f3d5 in start

Hi,

Can’t reproduce. I’ve created a dynamic particle attachment (which uses pin constraints under the hood). Entered play mode, no crash. Several sample scenes use dynamic attachments, too. None of them crashes.

Can you give more details? Platform used, exact Obi version, step by step to reproduce it, etc.

Edit: Just figured out that by "Enter play mode" you might mean the new experimental options in the enter play mode menu in 2019.3 (Project Settings > Editor > Enter Play Mode options), specifically domain reload disabling. This is not yet supported. By disabling domain reloading, all static data will be wiped out from loaded scripts. We use a static dictionary to keep track of colliders, so any pin constraints referencing them will hit a null ref exception because the collider refs are no longer there. We also use static event handlers to signal colliders for update, this is also not fully supported by disabled domain reloading.

We're working to support this in upcoming versions, but requires a quite in-depth refactor of the collider/attachment system. The workarounds described in Unity's documentation to deal with static data reloading do not work in our case.

For now, domain reloading must be enabled. Note that not even all official Unity packages will work with this new feature though. Quoting Unity's 2019.3 manual:

Quote:Note: This feature is experimental. Not all packages are validated as compatible with disabled Domain and Scene Reloading, and the behaviour of the feature might change in future versions of Unity.
Reply
#3
Wow, just wrote a reply and lost it because zip file was attached. Astuto


So, thanks for a quick reply. I'm not using the experimental "Configurable Enter Play Mode" feature (even though I tired to  Sonrisa ). I'm on macOS Mojave 10.14.6 + Unity 2019.3.0f6 + Obi5.1. Here is a minimal repro project - https://www.dropbox.com/s/7o441ajp3rhncn...t.zip?dl=0
Steps to repro:
1. open HarpoonTest scene
2. Play
3. click anywhere
4. 100% reproducible crash
I believe I'm doing something bad in HarpoonBehaviour.LaunchHook() (it is a modified version of an example). Please let me know how to fix it or if you need more info on the issue.
Reply
#4
(30-01-2020, 12:29 AM)iliakot Wrote: Wow, just wrote a reply and lost it because zip file was attached. Astuto


So, thanks for a quick reply. I'm not using the experimental "Configurable Enter Play Mode" feature (even though I tired to  Sonrisa ). I'm on macOS Mojave 10.14.6 + Unity 2019.3.0f6 + Obi5.1. Here is a minimal repro project - https://www.dropbox.com/s/7o441ajp3rhncn...t.zip?dl=0
Steps to repro:
1. open HarpoonTest scene
2. Play
3. click anywhere
4. 100% reproducible crash
I believe I'm doing something bad in HarpoonBehaviour.LaunchHook() (it is a modified version of an example). Please let me know how to fix it or if you need more info on the issue.

Hi,

You've added just one pin constraint, but immediately after that you declare that the amount of active constraints is 2:

Quote:batch.AddConstraint(blueprint.activeParticleCount - 1, target.GetComponent<Collider>().GetComponent<ObiColliderBase>(),
                                                         target.GetComponent<Collider>().transform.InverseTransformPoint(target.transform.position), Quaternion.identity);
       batch.activeConstraintCount = 2;

This will of course cause an out of bounds access and possibly an immediate crash (if you're lucky). Note that constraint data is not checked for bounds or null accesses in Oni (the internal physics engine) for performance reasons, so by doing this the engine is accessing memory past the end of the constraints array. Working with constraints is similar to working with Unity DOTS with safety checks disabled. From the docs:

Quote:As mentioned above, the size you pass must not be larger than the actual length of the array. Behavior is undefined (including the possibility of a crash) if you pass an array length that is larger than the actual length.

Solution - just change it to:

Quote:batch.activeConstraintCount = 1;
Reply
#5
Thanks a lot! Now works nicely, was my mistake. Would be nice to have some kind of "safe" mode when the performance is secondary and all errors are printed into the console. I don't know how big of a task it is and how many developers will benefit from it but this feature will definitely make it more user friendly (especially for beginners).
Reply
#6
(30-01-2020, 11:24 PM)iliakot Wrote: Thanks a lot! Now works nicely, was my mistake. Would be nice to have some kind of "safe" mode when the performance is secondary and all errors are printed into the console. I don't know how big of a task it is and how many developers will benefit from it but this feature will definitely make it more user friendly (especially for beginners).

Hi there!

We've rolled out our own Jobs+SIMD+Entities system under the hood, because when we started building Obi DOTS was not even a thing. But now I see little interest in reinventing the wheel, so we're working on porting the core engine to Jobs+Burst.

One of the additional benefits is we will be able to take advantage of Unity's built-in safety system. Also, much better platform support. See:
http://blog.virtualmethodstudio.com/2020...nds-burst/
Reply