libovravatar.dll (version 1.2.3.0) Causing unlogged crashes — Oculus
Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

libovravatar.dll (version 1.2.3.0) Causing unlogged crashes

wallacet_mfmwallacet_mfm Posts: 2
NerveGear
edited June 13 in Unity Development
Context info (from OVRManager's console log):
Unity v2018.2.21f1, Oculus Utilities v1.37.0, OVRPlugin v1.37.0, SDK v1.38.0.
---Yesterday, the sdk version was also 1.37.0, I'm not quite sure how that updated but the crashes have happened with both versions.

The crashes are not logged in Unity's output log, nor are there any hints as far as I could tell. I used the OculusLogGatherer tool to finally find what was causing the crash. I'll paste the event logs.

The Unity application we're developing is a crane simulation, where we teach the player how to give specific hand gestures/motions to signal a crane. To help with that, we use the Oculus avatar system to record a developer giving the correct signals and play the recording back at runtime for the player to mimic. This project has been in development for 2 years and we have updated our Unity version and Oculus sdk and plugin a few times over that span. The signal recordings were taken a long time ago and we have updated our project since then.

So far, the crashes have not occurred predictably; we can sit and watch the recordings playback for several minutes, starting and stopping as expected. Then, in the middle of one of the recordings, the editor (or build) will crash. I haven't been able to establish a clear pattern for it, but it might be related to starting a new recording soon after ending a previous one, but that is a low confidence guess. The crashes occur both on our development machines and on Valve's test machines, which is unfortunately how we first noticed the crashes. I'm guessing our QA team flew through the tutorial so fast that the problem didn't show up.

Here are the event logs capturing the crashes, some in the editor and one in the player:
Faulting application name: Signal Person Training.exe, version: 2018.2.21.8949, time stamp: 0x5c73f900
Faulting module name: libovravatar.DLL, version: 1.2.3.0, time stamp: 0x5cdb398c
Exception code: 0xc0000409
Fault offset: 0x000000000004c23c
Faulting process id: 0x1968
Faulting application start time: 0x01d5212f09126f1a
Faulting application path: C:\Program Files (x86)\Steam\steamapps\common\CLS Signal Person\Signal Person Training.exe
Faulting module path: C:\Program Files\Oculus\Support\oculus-runtime\libovravatar.DLL
Report Id: c1a76a9f-e118-4675-bae6-6308941d7cf2
Faulting package full name: 
Faulting package-relative application ID: 
Faulting application name: Unity.exe, version: 2018.2.21.8949, time stamp: 0x5c73f759
Faulting module name: libovravatar.DLL, version: 1.2.3.0, time stamp: 0x5d003cf3
Exception code: 0xc0000409
Fault offset: 0x000000000004cc3c
Faulting process id: 0x3188
Faulting application start time: 0x01d521e815270000
Faulting application path: C:\Program Files\Unity\Hub\Editor\2018.2.21f1\Editor\Unity.exe
Faulting module path: C:\Program Files\Oculus\Support\oculus-runtime\libovravatar.DLL
Report Id: 208d504e-7332-474f-b614-47dc04020bc3
Faulting package full name: 
Faulting package-relative application ID: 
Faulting application name: Unity.exe, version: 2018.2.21.8949, time stamp: 0x5c73f759
Faulting module name: libovravatar.DLL, version: 1.2.3.0, time stamp: 0x5d003cf3
Exception code: 0xc0000409
Fault offset: 0x000000000004cc3c
Faulting process id: 0x1e2c
Faulting application start time: 0x01d521f05faa3373
Faulting application path: C:\Program Files\Unity\Hub\Editor\2018.2.21f1\Editor\Unity.exe
Faulting module path: C:\Program Files\Oculus\Support\oculus-runtime\libovravatar.DLL
Report Id: 59ac9a4a-6b19-42d5-badf-eedd001667db
Faulting package full name: 
Faulting package-relative application ID: 

After investigating the reported exception code, it looks like this is a stack buffer overflow fault, according to this Microsoft forum (https://social.msdn.microsoft.com/Forums/sqlserver/en-US/aa84a49e-6bfe-4b89-928a-ea477e73c07e/clr-exception-0xc0000409?forum=clr)

and supported by other search results.

I couldn't find any information on my version of libovravatar.dll (1.2.3.0), but since it's part of the runtime I expect Oculus to automatically update this.

Our recording and playback system is based on the provided sample scripts in Assets/Oculus/Avatar/Samples/RemoteLoopback and the guide found here: https://developer.oculus.com/documentation/avatarsdk/latest/concepts/avatars-gsg-unity/

Here's the playback code:

        TextAsset asset = Resources.Load(filename) as TextAsset;
        if (asset != null)
        {
            MemoryStream s = new MemoryStream(asset.bytes);
            reader = new BinaryReader(s);
            loadPacket();
        }
    /// <summary>
    /// This is called recursively for every frame in the avatar recording.
    /// </summary>
    void loadPacket()
    {
        if (reader.BaseStream.Position >= reader.BaseStream.Length)
        {//If we've reached the end of the file, load it again and start over.
            reader.Close();
            this.DelayedInvoke(delegate { loadFile(); }, .1f);
            return;
        }

        int sequence = reader.ReadInt32();

        int size = reader.ReadInt32();
        byte[] sdkData = reader.ReadBytes(size);
        IntPtr packet = CAPI.ovrAvatarPacket_Read((UInt32)size + 8, sdkData);
        OvrAvatarPacket p = new OvrAvatarPacket {ovrNativePacket = packet};
        remoteAvatar.GetComponent<OvrAvatarRemoteDriver>().QueuePacket(sequence, p);
        this.DelayedInvoke(delegate { normalize(); loadPacket(); }, remoteAvatar.PacketSettings.UpdateRate);
    }
private void OnDestroy()
    {
        if (reader != null)
        {
            reader.Close();
        }
        if (remoteAvatar)
        {
            Destroy(remoteAvatar.gameObject);
        }
    }
normalize() adjusts the scale and position of the playback avatar to make it look nice and appear where we expect.

I'm hoping someone can tell me if this is a bug on Oculus' end, or if we are using the api improperly in some subtle way I haven't discovered yet. In either case, Is there a suggested workaround? We could bypass the problem altogether by moving away from the avatar system and just tracking position and pose data ourselves, but that seems an awful waste.


Comments

  • wallacet_mfmwallacet_mfm Posts: 2
    NerveGear
    For posterity, if you run into this problem, it seems to be caused by this line
    IntPtr packet = CAPI.ovrAvatarPacket_Read((UInt32)size + 8, sdkData);
    Specifically, the +8. This exists because the Oculus sample code includes two extra int32s in their size calculation, which is a bug in their sample code. The first param to that function should be the size of the byte buffer being passed in, not the size of the buffer + the sequence and size ints. Because of those extra 8 bytes in length, the underlying CAPI will very rarely try to read beyond a boundary and immediately fault. So, the correct line is

    IntPtr packet = CAPI.ovrAvatarPacket_Read((UInt32)size, sdkData);
Sign In or Register to comment.