06-13-2019 08:11 AM
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-ex...)
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()normalize() adjusts the scale and position of the playback avatar to make it look nice and appear where we expect.
{
if (reader != null)
{
reader.Close();
}
if (remoteAvatar)
{
Destroy(remoteAvatar.gameObject);
}
}
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.
06-26-2019 08:51 AM
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);