Closed yhr28 closed 4 years ago
What version of Unity/Build platform are you using?
Can you send more info on your setup?
Unity Version, Build Platform, OS, Player Settings (Scripting Backend, API Compatibility Level) anything else that might be different from default settings.
Can you send more info on your setup?
Unity Version, Build Platform, OS, Player Settings (Scripting Backend, API Compatibility Level) anything else that might be different from default settings.
I have tried unity3d editor from 2017 to 2019.3, windows 10 64 bit system. Now I use unity3d 2019.3.My Player Settings is Default config.Will break down. It's just that I had to hold back from asking questions. Now our company's MMO is going to be tested. This problem is particularly dangerous in the next collapse of a large game project. Therefore, this question has been raised. Thank you very much!!!
Are you able to reproduce this issue consistently? Is it one of the example scenes that is crashing or does it happen randomly?
If it is a certain scene that is causing the crash, can you found out what part of the code is causing the crash? From the code you sent it looks like it is CollisionWorld.Dispose that is crashing. Is it always that method causing the crash or are there other methods causing crashes as well?
Are you able to reproduce this issue consistently? Is it one of the example scenes that is crashing or does it happen randomly?
If it is a certain scene that is causing the crash, can you found out what part of the code is causing the crash? From the code you sent it looks like it is CollisionWorld.Dispose that is crashing. Is it always that method causing the crash or are there other methods causing crashes as well?
It's a constant breakdown. As long as you run any example scene, there is a 60% or more probability of a crash. As long as libbulletc.dll is removed, unity3d does not import libbulletc.dll. There will be no breakdown.
Are you able to reproduce this issue consistently? Is it one of the example scenes that is crashing or does it happen randomly?
If it is a certain scene that is causing the crash, can you found out what part of the code is causing the crash? From the code you sent it looks like it is CollisionWorld.Dispose that is crashing. Is it always that method causing the crash or are there other methods causing crashes as well?
CollisionWorld.Dispose? It's it. Oh. I guess I didn't dispose of collisionworld in my scene. Does this result in a crash caused by a conflict in the process of importing libbulletc.dll in the process of closing or opening the scene? I'll try and join dispose. Thank you!
I added Dispose to my code, but the crash still exists. Is there any other way? Thank you!
It is the new log 0x00007FFBC48B3C96 (libbulletc) HACD_HACD_delete 0x00007FFBC48B3D2C (libbulletc) HACD_HACD_delete 0x00007FFBC4868ACC (libbulletc) btTranslationalLimitMotor2_getEnableMotor 0x00007FFBC48A9065 (libbulletc) HACD_HACD_delete 0x00007FFBC48A9114 (libbulletc) HACD_HACD_delete 0x00007FFBC48A9AF3 (libbulletc) HACD_HACD_delete 0x00007FFBC48A90D2 (libbulletc) HACD_HACD_delete 0x00007FFBC48B47A0 (libbulletc) HACD_HACD_delete 0x00007FFBC491FD74 (libbulletc) HACD_HACD_delete 0x00000002B30DECEC (Mono JIT Code) (wrapper managed-to-native) BulletSharp.CollisionWorld:btCollisionWorld_delete (intptr) 0x00000002B30DE8BB (Mono JIT Code) BulletSharp.CollisionWorld:Dispose (bool) 0x00000002B30DD0FB (Mono JIT Code) BulletSharp.DynamicsWorld:Dispose (bool) 0x00000002B30DCB4C (Mono JIT Code) BulletSharp.CollisionWorld:Finalize () 0x000000024B40C32C (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_virtual_voidthis (object,intptr,intptr,intptr) 0x00007FFBCA213739 (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\metadata\gc.c:369] mono_gc_run_finalize 0x00007FFBCA2123BE (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\metadata\gc.c:863] finalize_domain_objects 0x00007FFBCA212625 (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\metadata\gc.c:959] finalizer_thread 0x00007FFBCA1D5AA8 (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\metadata\threads.c:1042] start_wrapper_internal 0x00007FFBCA1D5836 (mono-2.0-bdwgc) [c:\build\output\unity-technologies\mono\mono\metadata\threads.c:1101] start_wrapper 0x00007FFC2E507BD4 (KERNEL32) BaseThreadInitThunk 0x00007FFC2F18CE71 (ntdll) RtlUserThreadStart
When the collision world is deleted and there are objects remaining in the world, then Bullet will internally try to access the dispatcher and broadphase objects to clean up any remaining collision pairs between the objects. Since Dispose is not explicitly called on all three of those objects (world, dispatcher, broadphase), then the objects are cleaned up by the garbage collector (Finalize + implicit Dispose) in arbitrary order. If the dispatcher and broadphase happen to be already disposed, then Bullet cannot clean up the collision pairs.
There is a workaround in more recent versions of BulletSharp that prevents this kind of crash, but it's not an ideal solution. See: https://github.com/AndresTraks/BulletSharpPInvoke/blob/master/BulletSharp/Collision/CollisionWorld.cs#L738 https://github.com/Phong13/BulletSharpPInvoke/blob/master/BulletSharpPInvoke/Collision/CollisionWorld.cs#L1040
This might not be the actual cause of the crash, but it was a common one in older versions of BulletSharp. You could get more information about what happens in the destructor by compiling a debug version of libbulletc.dll.
As a solution, you can try to Dispose in this order: 1) collision world, 2) dispatcher, 3) broadphase. Or you can try to remove all collision objects from the world before cleaning up. In any case, you should explicitly Dispose all IDisposable objects that you create in a .NET program. There are no cases where it makes sense to leave it to the garbage collector.
When the collision world is deleted and there are objects remaining in the world, then Bullet will internally try to access the dispatcher and broadphase objects to clean up any remaining collision pairs between the objects. Since Dispose is not explicitly called on all three of those objects (world, dispatcher, broadphase), then the objects are cleaned up by the garbage collector (Finalize + implicit Dispose) in arbitrary order. If the dispatcher and broadphase happen to be already disposed, then Bullet cannot clean up the collision pairs.
There is a workaround in more recent versions of BulletSharp that prevents this kind of crash, but it's not an ideal solution. See: https://github.com/AndresTraks/BulletSharpPInvoke/blob/master/BulletSharp/Collision/CollisionWorld.cs#L738 https://github.com/Phong13/BulletSharpPInvoke/blob/master/BulletSharpPInvoke/Collision/CollisionWorld.cs#L1040
This might not be the actual cause of the crash, but it was a common one in older versions of BulletSharp. You could get more information about what happens in the destructor by compiling a debug version of libbulletc.dll.
As a solution, you can try to Dispose in this order: 1) collision world, 2) dispatcher, 3) broadphase. Or you can try to remove all collision objects from the world before cleaning up. In any case, you should explicitly Dispose all IDisposable objects that you create in a .NET program. There are no cases where it makes sense to leave it to the garbage collector.
Thank you. I'll try again.
0x000000022E774DDC (Mono JIT Code) (wrapper managed-to-native) BulletSharp.CollisionWorld:btCollisionWorld_delete (intptr) 0x000000022E77497B (Mono JIT Code) BulletSharp.CollisionWorld:Dispose (bool) 0x000000022E7731AB (Mono JIT Code) BulletSharp.DynamicsWorld:Dispose (bool) 0x000000022E772BFC (Mono JIT Code) BulletSharp.CollisionWorld:Finalize () 0x00000002FF07B6EC (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_virtual_voidthis (object,intptr,intptr,intptr)
My unity3d editor crashes log. From this, it can be seen that libbulletc.dll causes frequent crashes. Thanks for updating libbulletc.dll.