+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Cloth (https://obi.virtualmethodstudio.com/forum/forum-2.html)
+--- Thread: Bug / Crash Crash in Windows 2019.3.0f6 (/thread-2069.html)
Crash in Windows 2019.3.0f6 - jwindr - 26-02-2020
I'm getting a crash from obi cloth both in the editor and in windows x86_64 builds. The crash details are the same for both, occuring in (libOni) Oridinal0.
It seems to occur when either instantiating or destroying prefabs with obi cloth attached. (It's hard to tell which since the application crashes at that point)
Details from the error.log follows:
Read from location 00000223C9B23790 caused an access violation.
Context:
RDI: 0x0000000000001630 RSI: 0x0000022bb00964c8 RAX: 0x0000022bb0025030
RBX: 0x0000000000001f40 RCX: 0x0000000000000180 RDX: 0x0000022bae35c010
RIP: 0x00007ff93b4d3d76 RBP: 0xfffffff819afe760 SegCs: 0x0000022b00000033
EFlags: 0x0000000000010206 RSP: 0x00000049f88ff5d0 SegSs: 0x0000022b0000002b
R8: 0x0000000000000080 R9: 0x0000000000000004 R10: 0x0000000000000187
R11: 0x000000000000017f R12: 0x0000022bd867cff0 R13: 0x0000022baafcd200
R14: 0x0000022bb02dd190 R15: 0x0000022bae1b12c0
Bytes at CS:EIP:
0f 28 04 28 0f 28 0c 38 0f 58 c8 44 0f 28 d0 0f
Mono DLL loaded successfully at 'F:\Steam\steamapps\common\...\MonoBleedingEdge\EmbedRuntime\mono-2.0-bdwgc.dll'.
Stack Trace of Crashed Thread 7048:
0x00007FF93B4D3D76 (libOni) Ordinal0
0x00007FF93B51E2F0 (libOni) GetPointCloudAnisotropy
0x00007FF93B5326A9 (libOni) GetPointCloudAnisotropy
0x00007FF93B5386D9 (libOni) GetPointCloudAnisotropy
0x00007FF93B5389C9 (libOni) GetPointCloudAnisotropy
0x00007FF93B55BBC0 (libOni) GetPointCloudAnisotropy
0x00007FF962377BD4 (KERNEL32) BaseThreadInitThunk
0x00007FF963EACED1 (ntdll) RtlUserThreadStart
RE: Crash in Windows 2019.3.0f6 - jp715 - 26-02-2020
Did you get the message "libOni.dll caused an Access Violation" in your error log? If so, I think I had a similar issue, although mine was caused by switching gameobject from active to not active, then back to active.
I think it was caused by the SortedPoints array of the SkinnedCloth component not being properly initialized before the updater/solver tried to use it to run BeginStep or SubStep. The order of operations can be a little hard to track, since LateFixedUpater uses coroutines. I don't know if this will help for your problem, but my fix was to enable/disable the gameobject with the cloth attached in a coroutine, after waiting for the end of a frame, this seemed to make sure that the skinned cloth component had time to fully run through one update/late update cycle to make sure everything was fully initialized.
RE: Crash in Windows 2019.3.0f6 - jwindr - 26-02-2020
(26-02-2020, 04:05 PM)jp715 Wrote: Did you get the message "libOni.dll caused an Access Violation" in your error log? If so, I think I had a similar issue, although mine was caused by switching gameobject from active to not active, then back to active.
I think it was caused by the SortedPoints array of the SkinnedCloth component not being properly initialized before the updater/solver tried to use it to run BeginStep or SubStep. The order of operations can be a little hard to track, since LateFixedUpater uses coroutines. I don't know if this will help for your problem, but my fix was to enable/disable the gameobject with the cloth attached in a coroutine, after waiting for the end of a frame, this seemed to make sure that the skinned cloth component had time to fully run through one update/late update cycle to make sure everything was fully initialized.
Thanks for the info. Yes, I did get that message in the error.log:
libOni.dll caused an Access Violation (0xc0000005)
in module libOni.dll at 0033:3b4d3d76.
I can't tell for sure if your suggestion is related to my problem. I've narrowed down my case to occurring when deactivating gameobjects with obi cloth, but doing so in a coroutine after WaitForEndOfFrame does not fix the problem. It still randomly crashes.
RE: Crash in Windows 2019.3.0f6 - jwindr - 26-02-2020
I've done some more testing and the problem doesn't seem to be related SortedPoints being unitialized. More details from additional testing:
- GameObjects with Skinned Cloth are created and their parent is immediately deactivated. Several frames later they are re-activated and the game/editor crashes.
- The crash is occuring when the solver is run after activating gameobjects with Skinned Cloth. (I mistakenly thought it was on deactivation in my previous post)
- Changing when the activation happens doesn't solve the problem. Neither WaitForEndOfFrame or WaitForFixedUpdate prevent crashes.
- The crash occurs randomly. Less than 50% of the time, but frequently enough that I can easily reproduce it.
- The crash does NOT seem to happen when instantiating the same model without activation/deactivation and outside of any coroutine.
- I added logging to ObiSkinnedCloth and can see that it is copying 1227 from bakedVertices to sortedPoints before the crash.
RE: Crash in Windows 2019.3.0f6 - jp715 - 26-02-2020
Is it possible to instantiate the game objects with skinned cloth with the only cloth components already disabled? And then enabling the cloth components for the first time after the game objects are re-activated?
RE: Crash in Windows 2019.3.0f6 - jwindr - 26-02-2020
(26-02-2020, 10:27 PM)jp715 Wrote: Is it possible to instantiate the game objects with skinned cloth with the only cloth components already disabled? And then enabling the cloth components for the first time after the game objects are re-activated?
Yes, disabling the cloth components does fix the crash! Thanks!
After testing some things out, I can disable the cloth components in Awake (called during Instantiate), and re-enable them in Start (called after the GameObject is re-activated) and it also prevents the crash.
RE: Crash in Windows 2019.3.0f6 - josemendez - 27-02-2020
(26-02-2020, 11:44 PM)jwindr Wrote: Yes, disabling the cloth components does fix the crash! Thanks!
After testing some things out, I can disable the cloth components in Awake (called during Instantiate), and re-enable them in Start (called after the GameObject is re-activated) and it also prevents the crash.
Hi there,
Will try to reproduce this and find out the cause. By the looks of it, might be related to the -essentially random- order in which Unity calls Awake for different components in an object.