Bug / Crash Invalid memory access using libOni backend

[pdinklag]

Hi there!


GetPointCloudAnisotropy() is only called when there's fluid particles present in a solver. I assume you're only using ObiRope, so this method is never actually called. The fact that it appears in the stack trace is a very strong indicator that this issue stems from memory corruption: use of uninitialized memory, out of bounds access on unmanaged memory buffers, etc.

You mention this happens in both backends as well, which makes sense since both backends have identical memory access patterns.

Bad news is that despite the diagnosis being straightforward, these are extremely hard to debug since they can be caused by *literally anything* in your project, including code that's completely unrelated to Obi. The stack trace points you to where the program crashed, but there's no indication to where memory is being incorrectly handled.

The only ways to debug this are either using a memory debugger (Valgrind), and/or slowly dissect the project in a binary-search fashion until the issue disappears, then begin re-adding stuff until the issue is narrowed down.

I see. I'm not sure what Unity does by itself, but the only unmanaged code I'm using apart from libOni (or the Burst backend) is the Steamworks API, and that wasn't being used (to my knowledge - I'll make sure about it). So whatever memory corruption occurs should be caused by Obi or Steamworks, I'm not that deep into Unity's Mono that I'd know what managed code could possibly cause this (I am not using any other Burst code either).

But yes, these things are nasty to debug. Valgrind may be an option, I never used it on Windows but I'll have a look. Did you build the dll in "RelWithDebInfo" mode or similar, because apparently there are unmangled function names?

Ropes themselves do not perform any kind of memory handling at runtime: once instantiated, they do not allocate anything nor are they moved around in memory. It's safe to assume that ropes are not the culprit. You do mention that there's many rigidbodies/colliders being enabled/disabled at runtime, and that the issue happened in-editor while working on procedural generation of these: that's a good starting point.

Could you share more details about the pattern in which these are enabled/disabled? Ideally, share the script(s) you use to procedurally generate these?

In the Editor, it happened very sporadically as well. I should probably also note that I recently disabled domain reloading; I made sure my entire project supports this and it works fine, but of course, I don't know about the effect this may have on Obi. In any event, the crashes happened before I did this and also, this has absolutely no effect on builds, so it's very probably not to blame.

The ropes are generated procedurally as well, but only once in the beginning and then they're just there. I use Obi rigidbodies and colliders for the body parts of characters (capsules and boxes that belong to the ragdoll), as well as for the various weapons you see (steel chairs, baseball bats etc.), such that they may interact with the ropes. They are created once when the corresponding character or weapon is instantiated, and destroyed once the character leaves (after being eliminated from the game) or the weapon is destroyed (some can break). I don't have any special handling for destruction; I rely on ObiCollider's and ObiRigidbody's OnDestroy implementations here.

The creation looks about like this for characters:

Code:

            _obiColliders = new ObiCollider[num];
            _obiRigidbodies = new ObiRigidbody[num];
            for (var i = 0; i < num; i++)
            {
                var c = colliders[i];
                var oc = c.gameObject.AddComponent<ObiCollider>();
                oc.Thickness = Settings.Ragdoll.ObiColliderThickness;
                oc.Filter = ObiUtil.RagdollPartFilter;
                oc.enabled = _obiCollidersEnabled;
                _obiColliders[i] = oc;

                var r = rigidbodies[i];
                _obiRigidbodies[i] = r.gameObject.AddComponent<ObiRigidbody>();
            }

Nothing special in my book. It looks about the same for weapons and only happens once in their Start method.
For characters, the colliders are only ever capsules and boxes, and each ObiRigidbody has exactly one ObiCollider; weapons may also have (convex) mesh colliders and furthermore multiple ObiColliders per ObiRigidbody.

Enabling and disabling happens very often, in fact. Basically, whenever I make a rigidbody kinematic in Unity, I disable its ObiColliders.
Characters become kinematic once they become controllable by the player, and non-kinematic when they ragdoll. This happens very often in gameplay. Weapons become kinematic once picked up and "attached" to the character, and they become non-kinematic again when being dropped.

Code:

var kinematic = _rigidbody.isKinematic;
foreach (var c in _colliders) c.obiCollider.enabled = c.collider.enabled && !kinematic;

As you see, I use the "enabled" flag for it - is there a different or preferred way?

After giving it some thoughts, these are more things that I could imagine causing issues:

• I'm not enabling and disabling in FixedUpdate necessarily, but pretty much whenever. May this be an issue?
  
• I keep the ObiRigidbodies enabled. Should I disable them as well?
  
• There may be occasions where I enable or disable an ObiCollider and they are destroyed in the same frame, at least I can't rule it out now. Could this cause desyncs of sort?
  
• I spotted some code for my characters that synchronizes the ObiRigidbodyies' kinematicForParticles flags with the rigidbodies' isKinematic state. That is leftover code which I just removed, because I decided I don't want any rope interaction when rigidbodies are kinematic. This also happened as often as characters were switching between control and ragdoll.