Commented Issue: Continuous Allocation of V8ScriptEngine Can Crash Application [106]

When allocating a V8ScriptEngine objects within a loop causes memory to remain allocated even if you force all references to the object to null and eventually crashes the application with a System.AccessViolationException. The details of the crash is below.

_Currently coding against version 5.4.5.0 of ClearScript._

__This Code Snippet Fails (Normally at iteration 134 the failure occurs)__
for (int i = 1; i <= 1000; i++)
{
var v8Engine = new Microsoft.ClearScript.V8ScriptEngine();
v8Engine = null;
}

__This Code Snippet Works:__
for (int i = 1; i <= 1000; i++)
{
var v8Engine = new Microsoft.ClearScript.V8ScriptEngine();
v8Engine = null;
//Invoking Garbage Collection Every 50 V8ScriptEngine object allocated
//Fixes the issue
if(i%50 == 0)
GC.Collect();
}

__Here are the details of the crash:__
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: ClearScriptDemo.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 572a5c94
Problem Signature 04: ClearScriptV8-32
Problem Signature 05: 5.4.5.0
Problem Signature 06: 56e184c1
Problem Signature 07: e6
Problem Signature 08: 78
Problem Signature 09: System.AccessViolationException
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Comments: Hi again, ​ >Thanks for looking into the memory issue. Let me know what you find. ​ It's a ClearScript bug. When a `V8ScriptEngine` instance is disposed or finalized, ClearScript neglects to dispose one script object - an exception object created upfront and reserved for out-of-memory situations. Normally this doesn't matter as the entire runtime is destroyed immediately thereafter, but in the shared runtime case that one object apparently prevents the garbage collection of a sizable object graph. Thank you so much for finding this bug! We're tracking it [here](https://clearscript.codeplex.com/workitem/107). As for your approach, it definitely sounds reasonable. If you can trust your scripts to clean up after themselves, then you can simply reuse one engine per runtime. But if your scripts are untrusted (e.g., user-supplied), then it makes sense to create a fresh engine for each. Just remember to dispose the engine after running the script, and to invoke the runtime's garbage collector once in a while. With the latter approach you'll definitely need a fix for the bug you found; we'll post that shortly. Thanks again!