Prevent GameLift from terminating a crashing process

We have an issue where it looks like GameLift is terminating our process while we are processing a crash. In our crash handler we freeze all threads except the for the thread processing the exception (best effort to retain the state of the process at the time of the crash). This is likely causing GameLift to kill our process since we aren’t responding to the onHealthCheck().

Can we either:

  • Make a call to GameLift to tell it we are going dark and not to kill the process?
  • Increase the timeout for killing a process when the health check isn’t responded to?

Hello @GenericUser,

Sorry, neither of these options is possible. Unless you can continue responding to health checks in your crash dump handler, your process will be summarily terminated by GameLift.

You may be able to think creatively about how you might defeat this mechanism. NICE AuxProxy for long enough for your process to finish cleaning up, for instance, or make it so that AuxProxy temporarily has permissions removed so it cannot terminate the process. Bear in mind that this could lead to side-effects in other game sessions. But some type of duct tape and string method might work.

Thank you,

Al Murray :slight_smile:
Solutions Architect, Amazon Game Tech

Does the API provide any means to allow me to get the thread id of the thread that calls OnHealthCheck()? This way I could avoid freezing the GameLift health check thread while processing the crash.

I didn’t see anything for this in the documentation, but it would be a preferred mechanism as opposed to me tracking which thread is receiving the callback.


Hi @GenericUser,

No, it doesn’t. My working theory is that the SDK would spawn a new thread each time. I haven’t asked the thread what its ID is before but I doubt that it would remain the same from health check to health check, though an experiment might reveal an insight here.

Thank you,

Al Murray :slight_smile: Solutions Architect, Amazon Game Tech