Propagate `app crashed last session` from native layer to managed

[pistoleta]

Currently OOM crashes are sent on app restart before the scope is set. Since seems is not possible to bind that event to the scope... It would be really helpful I we could ask the SDK if there has been a crash on last session somehow, and then ourselves could send a different event like... 'This user (probably) had a OOM' In which we would bind the scope..attach the device logs and everything we need to find what was the player doing. This would be really helpful on beta testing to find memory sensitive spots during the game.

Thanks!

[bitsandfoxes]

Hey @pistoleta and thanks for raising this. To provide more information (from the discussion on Discord): The OOM issue coming through the Cocoa SDK is based on heuristics. The SDK sends this during start-up and the C# layer never gets to see it/apply any additional information to it. The reason it is currently done like this: Since it's based on heuristics about the previous run, there is very little context information that is guaranteed to be correct. Instead of reporting possibly wrong information, the SDK opts not to include them.

We will be looking into what context information actually persists (hardware is unlikely to have changed) and how to communicate the event between SDKs.

[philipphofmann]

@pistoleta, what you could do already now is use beforeSend on the native layer and check if it's an OOM. Then you could add extra information to this event. We don't have the possibility to add attachments in beforeSend yet, but we are soonish going to add this to Android. For iOS, I can't give you an ETA yet.

[pistoleta]

I could detect if its a OOM in the BeforeSend and set a flag to send a full report with the full context once the user has been identified then!

[pistoleta]

I'm trying to set a breakpoint in the BeforeSend while debugging on device to see how to discern between OOM exceptions but maybe the BeforeSend is being attached before the IDE is able to connect with the Unity process... How could I know from the BeforeSend if what's being sent is an OOM event?

[bitsandfoxes]

The BeforeSend @philipphofmann is referring to is the one from the Cocoa SDK. You'd need to extend the generated Xcode with your own functionality.

[pistoleta]

Unfortunately I don't have the knowledge but I could try, it would be enough by setting some flag in playerPrefs for example. Would this be possible to do in the cocoa sdk layer and retreive it from the unity one?

[BenWilles]

We would also benefit a lot from this feature

[pistoleta]

@philipphofmann could you point me where's the beforeSend method in the cocoa sdk?

[pistoleta]

It would really help us finding the cause of this issues

[bitsandfoxes]

@philipphofmann could you point me where's the beforeSend method in the cocoa sdk?

The BeforeSend is a callback and part of the options object, just like in the Unity SDK. When you build for iOS we generate Objective-C options from the ones you set in Unity and write them to a file called SentryOptions.m. You could try to modify that file and implement your BeforeSend callback there to see if that works for you. Just be careful - the file is auto-generated and changes to it might get lost when triggering new builds from within Unity.

[pistoleta]

Seriously, given the risks and possible updates by your side I find it a little bit ridiculous. We are not asking too much, is it that hard to simply set a flag from the native BeforeSend so we can retreive it from unity side? I doubt is more than 1 line to add it to PlayerPrefs for example... We don't need a sophisticated solution right now just a way to know the device that has sent an OOM. Thanks

[bitsandfoxes]

Hey @pistoleta, sorry to be the source of your frustration. I can see where you are coming from and I'd be more than happy to just add that feature but it's just not that simple. Currently, there is no way to grab the flag you're asking for from the Cocoa SDK and provide it to the Unity SDK.

We intend to add some cross SDK sync functionality in the future, it's just not there yet.