Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Crash
#1
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=0B6Ry21...GZRM2RZcGM

Thanks.

-L
Reply
#2
(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=0B6Ry21...GZRM2RZcGM

Thanks.

-L

Sure! we´ll take a look at the dmp to see what's causing the crash. 
Reply
#3
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,
Reply
#4
(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,

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=0B6Ry21...DhnYU85U3c
Reply
#5
(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=0B6Ry21...DhnYU85U3c

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.
[Image: 287ncoy.png]
Reply
#6
(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.
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?
Reply
#7
(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?

Hi!

Honestly I think this is most likely a driver-related issue, little to do with Obi. I've been completely unable to reproduce the crash, and i´ve already tried in like 4 pcs, both with Nvidia and ATI GPUs. Also the fact that the dumps show the Nvidia drivers crashing is quite relevant.

Most people in fact complain about a similar crash in this exact same .dll when using a variety of games. I'd suggest to update the GPU drivers and see if the situation improves.

If you can provide a repro project/scene I'll be more than eager to test it and see if I can get it to crash, though.
Reply