fix: steam crash

[kingstone426]

https://app.zenhub.com/workspaces/engine-group-5fb3b64dabadec002057e6f2/issues/gh/coherence/unity/4772

I am not 100% sure this solves the problem. Haven't had a crash for a while now but they are somewhat rare.
Regardless, I don't think this guard clause will hurt.

[zeroZshadow]

While this will fix the crash, I'm not sure if this is the right place for it.
Why is it trying to send Steam data on a closed connection?

[cbrisebois]

I haven't had this crash at all. I'm not against just throwing in safety returns. How could I repro this?

[kingstone426]

I haven't had this crash at all. I'm not against just throwing in safety returns. How could I repro this?

I don't have a solid repro, but it occurs sometimes when switching from the game scene back to the menu scene. It seems like I manage to get Steam into an invalid state while the connections are still alive and pumping.

[kingstone426]

While this will fix the crash, I'm not sure if this is the right place for it. Why is it trying to send Steam data on a closed connection?

You are probably right, this fix does not address (or understand) the actual underlying problem. I don't think it is that the connection is closed though, but something is clearly wrong.

[kingstone426]

I am in full allergy braindead mode right now, but I came across this bug on the Steamworks.NET repo (not the one we are using).

Lastly, since the data is not pinned or in any way retained for the native Steamworks components, the .NET memory manager is free to move the data around in memory and garbage-collect it while Steam is still trying to use it, which is bound to crash eventually.

rlabrecque/Steamworks.NET#421

Perhaps the ArraySegment passed to the native function is somehow being cleaned up just as the packet is being sent?
Although, the ArraySegment should clearly be in scope during the entire managed function call that includes the native function call, so it should never be freed before it returns...

[kingstone426]

Fixed with #4