We have a situation where our program may stop and perform cleanup if a certain activity is performed.

When this happens, the program cleans up all objects that have been created.

The problem is that one of these objects may be responsible for the activity.

This is the order of execution:

Object calls an Angelscript function

Function performs an activity that triggers cleanup

Cleanup removes the object, along with the handler for the AS call, resulting in the context being returned to the context pool

Another AS call is done to clean up the script, but this reuses the returned context, which has not been properly unprepared

All calls after this fail due to the error state.

It would be nice to be able to force a context to be reset at any point, like an abort, only Execute doesn't have to process it to abort execution.

Since the context is still marked as active, i can't call Execute again to process the abort.

Unfortunately, the context is never allowed to end execution, due to the use of a C style longjmp that skips past the call. The context is stuck in active mode, and can't be stopped.

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.