My unity3d editor crashes log.

[phong13]

My unity3d editor crashes log.

[Phong13]

What version of Unity/Build platform are you using?

[Phong13]

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.

[yhr28]

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!!!

[Phong13]

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?

[yhr28]

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.

[yhr28]

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!

[yhr28]

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_void__this__ (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

[AndresTraks]

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.

[yhr28]

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.