Quantcast
Channel: ClearScript
Viewing all 2297 articles
Browse latest View live

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

$
0
0
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, When you dispose a V8 script engine or runtime, only its unmanaged resources are cleaned up immediately. It's up to the .NET garbage collector to reclaim the managed memory. Consider also that the runtime is what manages V8's memory, so disposing a script engine that shares its runtime with others isn't likely to free up memory until the runtime invokes _its_ garbage collector or is itself disposed. From your description it isn't obvious which resources you're monitoring, nor how you're determining whether memory is being released. Can you provide more information? Thanks!

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

$
0
0
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: _Using SysInternals ProcessExplorer I captured some screen shots of the performance metrics of my test application. The images are attached in a zipped file (V8 Engine Allocation Investigation.Zip). Below is a breakdown of the images in the zip file._ _Please let me know if there is any more information that I need to provide._ __Set of Images showing performance profile when disposing of V8Runtime every 50 allocations/deallocation operations of V8ScriptEngine__ *Image 1: Allocation and Deallocation of 1000 V8ScriptEngines with Dispose of V8Runtime very 50 allocations.png *Image 2: Allocation and Deallocation of 1000 V8ScriptEngines with Dispose of V8Runtime very 50 allocations (Process Details).png *Image 3: Allocation and Deallocation of 1000 V8ScriptEngines with Dispose of V8Runtime very 50 allocations (.NET CLR Memory Details) __Set of Images showing performance profile when NOT disposing of V8Runtime every 50 allocations/deallocation operations of V8ScriptEngine__ *Image 4: Allocation and Deallocation of 1000 V8ScriptEngines WITHOUT Dispose of V8Runtime very 50 allocations.png *Image 5: Allocation and Deallocation of 1000 V8ScriptEngines WITHOUT Dispose of V8Runtime very 50 allocations (Process Details).png *Image 6: Allocation and Deallocation of 1000 V8ScriptEngines WITHOUT Dispose of V8Runtime very 50 allocations (.NET CLR Memory Details) __Code Snippet ran when capturing performance metrics.__ private void AllocateV8Engines() { V8ScriptEngine v8Engine = null; V8Runtime _v8Runtime = new V8Runtime(); try { for (int i = 1; i <= 1000; i++) { v8Engine = _v8Runtime.CreateScriptEngine(); v8Engine.Dispose(); //chkDisposeRuntime is a Checkbox control is used to determine //whether to dipose of V8Runtime or not. if (chkDisposeRuntime.Checked && i%50 == 0) { _v8Runtime.Dispose(); _v8Runtime = new V8Runtime(); } } } catch (Exception ex) { MessageBox.Show(ex.Message); } }

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

$
0
0
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: Here are the images. Not sure if they got attached

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

$
0
0
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: try this again

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

$
0
0
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: Sorry for uploading so many times. I kept getting a message from my browser warning me that I was leaving the page and that I would lose my changes.

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

$
0
0
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: No problem at all! Thanks for adding the images. We'll take a look.

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

$
0
0
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: Thanks again for posting the images. The Performance Graph screen shots clearly demonstrate a difference, but we're not sure there's anything unexpected there. Disposing a V8 runtime instantly releases all of its unmanaged memory. That includes all the memory occupied by its garbage-collected heap, which holds the objects of all its child engines. If you don't dispose the runtime, then its heap keeps growing as new engines are created. You may be wondering why disposing an engine doesn't deallocate its objects immediately. That's simply due to the garbage-collected nature of the runtime's heap. With a shared runtime, disposing an engine makes its objects _eligible_ for garbage collection, but the garbage collector doesn't run immediately; in fact, V8's garbage collector is rather lazy. Instead of disposing your runtime periodically, try invoking its garbage collector via `V8Runtime.CollectGarbage(true)`. That should yield similar results. Good luck!

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

$
0
0
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: Thank you again for your quick response. Your explanation is very clear in terms of the managed memory. I tried the CollectGarbage routine and that unfortunately did not work. I have a question? Does the V8Runtime object store a reference to the V8ScriptEngine object it creates. If so, that may explain why the garbage collector does not clean up the managed memory. Although the V8ScriptEngine has been marked for disposal, if the V8Runtime is still referencing the object, wouldn't the garbage collector overlook cleaning up the memory until the V8Runtime object's reference count is 0? We plan to use ClearScript in a high performance application and we want to minimize the overhead of initializing script engines. Our model may require several hundreds of script engines to be initialized at startup. I think we can leverage allocating a few V8Runtime objects (i.e one per core) and then allocate a large set of V8ScriptEngine objects per runtime. Another quick question. How many script engines per runtime do you suggest, and will this allocation strategy be multi-thread safe? Again thank you so much for the feedback. We are really impressed with the power of the ClearScript library and the ease to which we can integrate scripting into our code base. ERIC

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

$
0
0
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: One thing I forgot to mention is that from time to time we may have to reconfigure the initialized script engines by de-allocating and reallocating them. Hence the purpose of doing these type of allocation tests.

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

$
0
0
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 Eric, ​ >I tried the CollectGarbage routine and that unfortunately did not work. ​ We've run a few tests, and you're right; periodically forcing V8 garbage collection makes only a small difference in this scenario. It looks like creating an engine always leaks around a half-megabyte of V8 runtime heap. This may or may not be a ClearScript issue; we're investigating. In any case, creating a large number of engines that share a small number of runtimes may not be the right approach for you. Runtimes are single-threaded, so engines that share a runtime can't execute script code concurrently. Can you say more about what kind of script code your application will run? For example, will your scripts be long-running? Can each script be trusted to leave the engine in a good state for running other scripts? Thanks!

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

$
0
0
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: Thanks for looking into the memory issue. Let me know what you find. Regarding the scripts, we plan to use scripting for custom calculations on internal objects. Our approach is to link object instances with script identifiers via the AddHostObject() function. The calculation scripts should be very short lived. In the event the script is not short lived, we plan to take advantage of the V8ScriptEnging.Interrupt() function to limit the amount of time a script runs. Based on your feedback it sounds like we need to create a pool of V8Runtime objects that matches the number of cores on the target system, and then distribute the creation of engines evenly against the allocated V8Runtimes. So in essence we would queue engine objects, and then process each engine sequential order per V8Runtime. Does that sound feasible?

Created Issue: Memory leak with shared V8 runtimes [107]

$
0
0
Repeated calls to `V8Runtime.CreateScriptEngine` make the runtime's heap grow even if the engine instances are disposed immediately. This is because the `V8ContextImpl` destructor neglects to to dispose the termination exception.

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

$
0
0
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!

Edited Issue: [BUG] Memory leak with shared V8 runtimes [107]

$
0
0
Repeated calls to `V8Runtime.CreateScriptEngine` make the runtime's heap grow even if the engine instances are disposed immediately. This is because the `V8ContextImpl` destructor neglects to to dispose the termination exception.

Created Unassigned: cross-engine nested exception fault [108]

$
0
0
got one more cross-engine issue.

an error raised by scriptengine (b) which was invoked by another scriptengine (a), doesn't make it to scriptengine (a) and properly back to the origin calle in the stack scriptengine (b). which means the script execution error occurred as such in scriptengine (b) cant be catched by a try-catch on the host side.

on more weird issue happening along side is that the code block (function|sub) where the error was raised gets executed from the very beginning.

in short the call chain looks like this:
engineA.someMethod( ->
engineB.anotherMethod( ->
engineA.errorOccuringMethod( ->
..firstLineCode..
someErrorCode -> causes a rerun of engineA.errorOccuringmethod() then throwing COMException in WindowsScriptEngine.ThrowHostException()
)
)
)


here a sample code:

```
var seA = new VBScriptEngine();
seA.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seA.Execute(@"
class aclass

function binvoke(bobj)
bobj.bmethod()
end function

end class
dim avar : set avar = new aclass
");

var seB = new VBScriptEngine();
seB.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seB.Execute(@"
class bclass

function bmethod()
WriteLine(""begin-bmethod"")
err.raise 1, ""source"", ""errdescr""
bmethod = ""retval""
WriteLine(""end-bmethod"")
end function

function go(seA, bobj)
dim i
'for i = 0 to 5
seA.binvoke(bobj)
'next
end function

end class
dim bvar : set bvar = new bclass
");


try
{
seB.Script.bvar.go(seA.Script.avar, seB.Script.bvar);
}
catch (System.Runtime.InteropServices.COMException)
{
throw;
}
catch (Exception)
{
throw;
}
```


Edited Unassigned: cross-engine nested exception fault [108]

$
0
0
got one more cross-engine issue.

an error raised by scriptengine (b) which was invoked by another scriptengine (a), doesn't make it to scriptengine (a) and properly back to the origin calle in the stack scriptengine (b). which means the script execution error occurred as such in scriptengine (b) cant be catched by a try-catch on the host side.

on more weird issue happening along side is that the code block (function|sub) where the error was raised gets executed from the very beginning.

in short the call chain looks like this:
engineA.someMethod( ->
engineB.anotherMethod( ->
engineA.errorOccuringMethod( ->
- firstLineCode -
someErrorCode -> causes a rerun of engineA.errorOccuringmethod() then throwing COMException in WindowsScriptEngine.ThrowHostException()
)
)
)


here a sample code:

```
var seA = new VBScriptEngine();
seA.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seA.Execute(@"
class aclass

function binvoke(bobj)
bobj.bmethod()
end function

end class
dim avar : set avar = new aclass
");

var seB = new VBScriptEngine();
seB.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seB.Execute(@"
class bclass

function bmethod()
WriteLine(""begin-bmethod"")
err.raise 1, ""source"", ""errdescr""
bmethod = ""retval""
WriteLine(""end-bmethod"")
end function

function go(seA, bobj)
dim i
'for i = 0 to 5
seA.binvoke(bobj)
'next
end function

end class
dim bvar : set bvar = new bclass
");


try
{
seB.Script.bvar.go(seA.Script.avar, seB.Script.bvar);
}
catch (System.Runtime.InteropServices.COMException)
{
throw;
}
catch (Exception)
{
throw;
}
```

Edited Unassigned: cross-engine nested exception fault [108]

$
0
0
got one more cross-engine issue.

an error raised by scriptengine (b) which was invoked by another scriptengine (a), doesn't make it to scriptengine (a) and properly back to the origin calle in the stack scriptengine (b). which means the script execution error occurred as such in scriptengine (b) cant be catched by a try-catch on the host side.

on more weird issue happening along side is that the code block (function|sub) where the error was raised gets executed from the very beginning.

in short the call chain looks like this:
engineA.someMethod(
engineB.anotherMethod(
engineA.errorOccuringMethod(
- firstLineCode -
someErrorCode -> causes a rerun of engineA.errorOccuringmethod() then throwing COMException in WindowsScriptEngine.ThrowHostException()
)
)
)


here a sample code:

```
var seA = new VBScriptEngine();
seA.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seA.Execute(@"
class aclass

function binvoke(bobj)
bobj.bmethod()
end function

end class
dim avar : set avar = new aclass
");

var seB = new VBScriptEngine();
seB.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seB.Execute(@"
class bclass

function bmethod()
WriteLine(""begin-bmethod"")
err.raise 1, ""source"", ""errdescr""
bmethod = ""retval""
WriteLine(""end-bmethod"")
end function

function go(seA, bobj)
dim i
'for i = 0 to 5
seA.binvoke(bobj)
'next
end function

end class
dim bvar : set bvar = new bclass
");


try
{
seB.Script.bvar.go(seA.Script.avar, seB.Script.bvar);
}
catch (System.Runtime.InteropServices.COMException)
{
throw;
}
catch (Exception)
{
throw;
}
```

Edited Unassigned: cross-engine nested exception fault [108]

$
0
0
got one more cross-engine issue.

an error raised by scriptengine (b) which was invoked by another scriptengine (a), doesn't make it to scriptengine (a) and properly back to the origin calle in the stack scriptengine (b). which means the script execution error occurred as such in scriptengine (b) cant be catched by a try-catch on the host side.

on more weird issue happening along side is that the code block (function|sub) where the error was raised gets executed from the very beginning.

in short the call chain looks like this:
>engineA.someMethod(
> engineB.anotherMethod(
> engineA.errorOccuringMethod(
> - firstLineCode -
> someErrorCode -> causes a rerun of engineA.errorOccuringmethod() then throwing COMException in >WindowsScriptEngine.ThrowHostException()
> )
> )
>)


here a sample code:

```
var seA = new VBScriptEngine();
seA.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seA.Execute(@"
class aclass

function binvoke(bobj)
bobj.bmethod()
end function

end class
dim avar : set avar = new aclass
");

var seB = new VBScriptEngine();
seB.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seB.Execute(@"
class bclass

function bmethod()
WriteLine(""begin-bmethod"")
err.raise 1, ""source"", ""errdescr""
bmethod = ""retval""
WriteLine(""end-bmethod"")
end function

function go(seA, bobj)
dim i
'for i = 0 to 5
seA.binvoke(bobj)
'next
end function

end class
dim bvar : set bvar = new bclass
");


try
{
seB.Script.bvar.go(seA.Script.avar, seB.Script.bvar);
}
catch (System.Runtime.InteropServices.COMException)
{
throw;
}
catch (Exception)
{
throw;
}
```

Edited Unassigned: cross-engine nested exception fault [108]

$
0
0
got one more cross-engine issue.

an error raised by scriptengine (b) which was invoked by another scriptengine (a), doesn't make it to scriptengine (a) and properly back to the origin calle in the stack scriptengine (b). which means the script execution error occurred as such in scriptengine (b) cant be catched by a try-catch on the host side.

on more weird issue happening along side is that the code block (function|sub) where the error was raised gets executed from the very beginning.

in short the call chain looks like this:
```
engineA.someMethod(
engineB.anotherMethod(
engineA.errorOccuringMethod(
- firstLineCode -
someErrorCode -> causing a rerun of engineA.errorOccuringmethod() then throwing COMException in WindowsScriptEngine.ThrowHostException()
)
)
)
```

here a sample code:

```
var seA = new VBScriptEngine();
seA.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seA.Execute(@"
class aclass

function binvoke(bobj)
bobj.bmethod()
end function

end class
dim avar : set avar = new aclass
");

var seB = new VBScriptEngine();
seB.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seB.Execute(@"
class bclass

function bmethod()
WriteLine(""begin-bmethod"")
err.raise 1, ""source"", ""errdescr""
bmethod = ""retval""
WriteLine(""end-bmethod"")
end function

function go(seA, bobj)
dim i
'for i = 0 to 5
seA.binvoke(bobj)
'next
end function

end class
dim bvar : set bvar = new bclass
");


try
{
seB.Script.bvar.go(seA.Script.avar, seB.Script.bvar);
}
catch (System.Runtime.InteropServices.COMException)
{
throw;
}
catch (Exception)
{
throw;
}
```

Edited Unassigned: cross-engine nested exception fault [108]

$
0
0
got one more cross-engine issue.

an error raised by scriptengine (b) which was invoked by another scriptengine (a), doesn't make it to scriptengine (a) and properly back to the origin calle in the stack scriptengine (b). which means the script execution error occurred as such in scriptengine (b) cant be catched by a try-catch on the host side.

on more weird issue happening along side is that the code block (function|sub) where the error was raised gets executed from the very beginning.

in short the call chain looks like this:
```
engineA.someMethod(
engineB.anotherMethod(
engineA.errorOccuringMethod(
- firstLineCode -
someErrorCode -> causing a rerun of engineA.errorOccuringmethod() then throwing COMException in WindowsScriptEngine.ThrowHostException()
)
)
)
```

here a sample code:

```
var seA = new VBScriptEngine();
seA.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seA.Execute(@"
class aclass

function binvoke(bobj)
bobj.bmethod()
end function

end class
dim avar : set avar = new aclass
");

var seB = new VBScriptEngine();
seB.Script.WriteLine = new Action<string>((text) => Console.WriteLine(text));
seB.Execute(@"
class bclass

function bmethod()
WriteLine(""begin-bmethod"")
err.raise 1, ""source"", ""errdescr""
bmethod = ""retval""
WriteLine(""end-bmethod"")
end function

function go(seA, bobj)
dim i
'for i = 0 to 5
seA.binvoke(bobj)
'next
end function

end class
dim bvar : set bvar = new bclass
");


try
{
seB.Script.bvar.go(seA.Script.avar, seB.Script.bvar);
}
catch (System.Runtime.InteropServices.COMException)
{
throw;
}
catch (Exception)
{
throw;
}
```

you should see 2xtimes "begin-bmethod" in the console output before the debugger stop at WindowsScriptEngine.ThrowHostException()

the expected behaviour would be 1xtime "begin-bmethod" in the console output and break of the debugger in the try-catch block
Viewing all 2297 articles
Browse latest View live




Latest Images