(23-10-2017, 07:44 AM)Loft3411 Wrote: Hello!

I have users experiencing an intermittent crash while using Obi rope. They have a build running on a machine that crashes about twice
an hour. I have 3 ropes in a Oculus VR scene along with 3 separate obi solvers. I'm unable to reproduce this, so I'm sending you guys the crash dump to see if you may have some insight.

I'm using Unity 2017.1.0f3 and Obi Rope 3.2

Log:
https://drive.google.com/open?id=0B6Ry21IJFOFqWFRpbGZRM2RZcGM

Thanks.

-L

(23-10-2017, 11:15 AM)josemendez Wrote: The dump indicates a crash during collision detection. Seems that the internal spatial partitioning structure is asked to hold the index of a particle that does not exist in the solver arrays. This should be impossible under normal circumstances. We have been unable to reproduce this ourselves too (left some of the sample scenes running for about an hour now, still keep going), so we need more details on how is the asset being used.

Are you performing any kind of custom scripting of any kind? (collision callbacks, setting particle properties, etc). 

PD: also getting more dumps would be useful, as we can see if there's some kind of pattern leading to the crash.

cheers,

(23-10-2017, 05:42 PM)Loft3411 Wrote: Thank you for the quick response.

I'm  not performing any custom scripting - definitely no callbacks or setting of particle properties. I haven't extended ObiRope in any way.

With respect to collision, I have 3 ropes in the scene all of which are set to not simulate when invisible via the inspector. I just noticed one rope is set to collide with self - which is inconsistent with the other two.

On my dev machine, I've noticed a case where all simulation of the ropes stops, but never crashes.

I have included some additional logs here:

https://drive.google.com/open?id=0B6Ry21IJFOFqSEM2ZDhnYU85U3c

(23-10-2017, 08:16 PM)josemendez Wrote: Hi,

Two of these dump files lead to an access violation in nvwgf2umx.dll, not inside libOni.dll. That library seems to be part of Nvidia drivers, so they could be contributing to the problem.
Still, the third dmp is exactly like the first one you sent: a crash when accessing data for an non-existent particle. We will try to reproduce it and get back to you.

(26-10-2017, 11:00 PM)Loft3411 Wrote: Just checking in on this.

Is there something I can do in my scene setup to potentially reduce my exposure to this ? ie. Setting up the obi solvers and ropes again?