cancel
Showing results for 
Search instead for 
Did you mean: 

Crash bug in SDK 0.2.5

jherico
Adventurer
The newly released SDK has an issue with SensorFusion that did not exist in 0.2.4.

The new implementation of SensorFilter instantiates a CircularBuffer object as a member, which in turn uses the OVR::Allocator in it's constructor to allocate some memory for the buffer. SensorFusion in turn, contains a SensorFilter object. This means that if you have a SensorFusion instance in your class and the class is instantiated before OVR::System::Init() is called, then it will crash with a null pointer access when it attempts to use the allocator.

For instance

class OvrWrapper {
public:
SensorFusion fusion;
OvrWrapper() {
OVR::System::Init();
}
virtual ~OvrWrapper() {
OVR::System::Destroy();
}
void run() {
... do something here ...
}
}

int main(int argc, char ** argv) {
OvrWrapper foo; foo.run();
}


Previously this code would work just fine, because none of the constructors did any dynamic allocation using OVR::Allocator. Now, this code crashes.

Actually, I'm pretty sure this will crash the existing Minimal Oculus Application as well, since it declares the SensorFusion object as a global, which will have its constructor called before the application calls OVR::System::Init in the example

I'm tracking this issue in the Git copy of the SDK here: https://github.com/jherico/OculusSDK/issues/25
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
11 REPLIES 11

StellaArtois
Protege
Beat me to it. Seen this as well.

ceydric
Honored Guest
Yep, found this problem too..
I'm hoping for a fix soon...
Thanks for the complete explanation jherico 😉

StellaArtois
Protege
I'm assuming we can just allocate it on the heap instead after OVR::System::Init() has been called; although I can't currently try this while at work.

Endox
Honored Guest
"StellaArtois" wrote:
I'm assuming we can just allocate it on the heap instead after OVR::System::Init() has been called; although I can't currently try this while at work.

This worked for me.

cybereality
Grand Champion
Sorry guys, I just updated the wiki tutorials.

Basically you just need to declare the SensorFusion object as a pointer, and then allocate it somewhere after your call to System::Init(). Not a huge change, but obviously it might break some apps based on the minimal tutorial.
AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV

wbvdw
Honored Guest
Thanks everyone, ran into this to. Wiki solved my issue. 🙂

nhoobler
Honored Guest
"cybereality" wrote:
Sorry guys, I just updated the wiki tutorials.

Basically you just need to declare the SensorFusion object as a pointer, and then allocate it somewhere after your call to System::Init(). Not a huge change, but obviously it might break some apps based on the minimal tutorial.


So just to be clear, is the proper behavior now to allocate a sensor result object on the heap, and then rely on the Sensor it's attached to to clean it up? i.e.


// Initialization /////////
OVR::System::Init();
OVR::Ptr<OVR::DeviceManager> device_manager = *(OVR::DeviceManager::Create());
OVR::Ptr<OVR::HMDDevice> display = *(device_manager ->EnumerateDevices<OVR::HMDDevice>().CreateDevice());
OVR::Ptr<OVR::SensorDevice> sensor = *(display->GetSensor());
OVR::SensorFusion * sensor_result = new OVR::SensorFusion(sensor);

// Use ////////////////
// ...

// Cleanup ////////////
// delete sensor_result; // Not needed because "sensor" will delete it now
sensor.Clear();
display.Clear();
device_manager.Clear();

OVR::System::Destroy();


I ask because I seem to be getting de-allocation related crashes if I delete the object myself.

cybereality
Grand Champion
Can you take a look at the example on the wiki?
https://developer.oculus.com/wiki/Minimal_Oculus_Application

The only major difference I see from your code is the order of the initialize and cleanup steps.

I believe you do still need to delete the pointer. Can you post the error you are getting?
AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV

jherico
Adventurer
"nhoobler" wrote:
So just to be clear, is the proper behavior now to allocate a sensor result object on the heap, and then rely on the Sensor it's attached to to clean it up? i.e.


// delete sensor_result; // Not needed because "sensor" will delete it now
sensor.Clear();


I ask because I seem to be getting de-allocation related crashes if I delete the object myself.


I wouldn't expect the SensorDevice to be responsible for cleanup of things it didn't allocate. Keep in mind that the SensorDevice class isn't reference counted like the *Device hierarchy of classes and can't be wrapped in a OVR::Ptr type.

I suspect any crashes you're seeing are related to the fact that you appear to have placed the deallocation of the sensor_result before you clear the sensor, and without having detached it as a listener. Try calling sensor_device->AttachToSensor(nullptr); before you call delete on it.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action