Problem when dealing with program exception state

How do you suggest this should be done?

You need to be very careful with longjmp. In controlled situations it is a perfectly valid solution, but if you don't have that control of the situation then you had better avoid using it. If you used longjmp to jump back to the top of the call-stack where the context is executing, then you lost all information on local variables, which means that there is no way for the context to clean up whatever might be needed in order to reset the status of the context.

Sure, you could forcibly update the state to 'aborted', which would in theory allow you to reuse the context. But I don't see how you would be able to guarantee that all memory is properly cleaned up (decreasing ref counters, calling destructors on value types, freeing memory blocks, etc).

Instead of immediately doing the cleanup upon the trigger I suggest you queue the cleanup for a later, Abort the script and allow the context to return normally from the Execute call. Unprepare the context to naturally release any resources still held by the context. Only after this are you safe to do the clean-up of the object, as you now know the script is not referring to it (unless of course the script is allowed to store references to it in global variables).

I figured that would be the case. The problem is that the code responsible for performing the longjmp is part of a game engine's error handling system, and we can't easily change that. I suppose we'll have to find a way to minimize the potential for problems then.

This type of error only happens if a critical error occurs, so we can advise a game restart here.

Thanks for looking into this.

What game engine are we talking about here? Is it a commercially available engine? An in-house engine? Is the engine written in C (hence the use of longjmp)?

If it is only happening in case of critical failure where the intention is not to continue processing anyway but just display a 'friendly' message that something bad happened and then restart the application, then you might as well simply discard the context without calling release on it or attempting any other cleanup. After such a critical failure, attempting to cleanup has a great risk of causing an even further problem from which you cannot recover, for example memory heap corruption, thus preventing you from displaying the 'friendly' message.

It's a modified GoldSource engine. When such an error occurs, you're thrown back into the main menu, so you can start another game.

The age (1998) and language ( C ) of that game engine explains the use of longjmp . Most likely it is a piece of code that is remainder from the even older Quake engine.

That's what we thought. We have access to the source code, but it will take time to refactor out the use of longjmp.