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

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: As I'm reading my own comments I see that I might come off as a bit aggressive which is very much not my intention. We are very greatful for this project (and we evaluated more than one C#2JS project before choosing ClearScript) and it works great. We're just happy that we've managed to solve the crashes and now wonder what the best approach is for keeping memory use in check without having to recreate engines and runtimes too often (as it's not a cheap operation).

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: Hi again, ​ >At first we had ~20 engines and runtimes that we never disposed, we just called CollectGarbage(true) on them for every 30 execution. This gave a slow buildup of memory. About one GB an hour. This gave us Access Violation crashes every 2-6 hours. ​ We'd still like to see a stack for that, preferably with symbols, although it _sounds_ as if a runtime is simply running out of memory. Even the 64-bit V8 limits runtimes to about 1.5 GB by default, and in our experience there's only so far you can push it by adjusting the constraints, as V8 appears to have a number of fixed-size internal buffers that aren't under the host's control. It also reserves huge blocks of address space for each runtime, although that shouldn't be a problem in 64-bit. In any case, V8 seems to treat all resource exhaustion conditions as fatal and potentially process-corrupting, so its response is always to kill the process immediately via an unrecoverable access violation. ​ >We only use ScriptEngine.Execute and ScriptEngine.Evaluate when we pass in JSON. For the main chunk of code we precompile at startup. ​ Can you elaborate on that? What calls do you make to precompile the code? Subsequently, how do you invoke the precompiled code? And how do you pass JSON to it? A couple of small samples might help identify potential optimizations. ​ >As I'm reading my own comments I see that I might come off as a bit aggressive which is very much not my intention. ​ Not at all! We're very interested in making ClearScript useful on the server, and we appreciate your help! Cheers!

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: We have a few dumps from the crashes. But without symbols unfortunately because we fixed it before we got around to adding symbols. And we haven't been aböe to reproduce it locally. The dumps are a few GB unzipped, what would be the best way to send them to you? When creating a new runtime/engine pair we compile the main bundle and execute it once using Runtime.Compile and Engine.Execute. The main bundle exposes a few global functions that we later call like this: var html = Engine.Evaluate<string>("renderToString(" + modelJson + ")"); Where renderToString is such a method and modelJson is a C# view model serialized to a JSON string.

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: >The dumps are a few GB unzipped, what would be the best way to send them to you? ​ Without symbols it's probably not worth it, especially if the crash occurs in V8 code. We'll be happy to look at a stack if you can get one by opening one of the dumps in Visual Studio, but it isn't likely to be helpful without symbols. ​ >var html = Engine.Evaluate<string>("renderToString(" + modelJson + ")"); ​ This suggestion may have little effect on your site's responsiveness, memory usage, or uptime, but consider that you are in fact invoking V8's JavaScript parser every time you call `renderToString` as shown above. This could be significant if, as you say, you're processing large JSON models. Instead, consider installing the following additional function at startup: ``` C# Engine.Execute(@" function renderJsonToString(modelJson) { return renderToString(JSON.parse(modelJson)); } "); ``` And then invoking it as follows: ``` C# var html = (string)engine.Script.renderJsonToString(modelJson); ``` This way you avoid parsing a script just to call a function, and you process your model with V8's JSON parser, which is much faster than its JavaScript parser.

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: Hi! We haven't had any crashes now since sunday, but today we got a new crash right after deploying a new version of the site. So it probably wasn't related to high memory use like we suspect that the previous crashes was (suspect but we're not 100% sure). Here's the stack trace we got from the dump: ``` v8-x64.dll!00007ffb36653a93() Unknown v8-x64.dll!00007ffb366d02fd() Unknown ClearScriptV8-64.dll!00007ffb35d93a3d() Unknown ClearScriptV8-64.dll!00007ffb35d93514() Unknown ClearScriptV8-64.dll!00007ffb35d913ff() Unknown [Managed to Native Transition] ClearScriptV8-64.dll!<Module>.std._Func_class<void>.()(std._Func_class<void>* value) Unknown ClearScriptV8-64.dll!Microsoft.ClearScript.V8.NativeCallbackImpl.Invoke() Unknown ClearScript.dll!Microsoft.ClearScript.Util.MiscHelpers.Try(System.Action action) Unknown ClearScript.dll!Microsoft.ClearScript.Util.NativeCallbackTimer.OnTimer(object state) Unknown mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Unknown mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) Unknown mscorlib.dll!System.Threading.TimerQueueTimer.CallCallback() Unknown mscorlib.dll!System.Threading.TimerQueueTimer.Fire() Unknown mscorlib.dll!System.Threading.TimerQueue.FireNextTimers() Unknown [Native to Managed Transition] kernel32.dll!00007ffb659713d2() Unknown ntdll.dll!00007ffb67e454e4() Unknown ``` Is this actionable for you?

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: The stack is quite specific but not really actionable; in fact, it looks like it might be a V8 issue. V8 has a mechanism whereby, during script execution, it sometimes tells the host, "Hey, call me back in about N seconds". V8's API documentation says nothing about the purpose of these deferred tasks, but they usually have to do with resource cleanup of one kind or another. The stack indicates that ClearScript is calling back to V8 to perform such a task, and apparently V8 crashed. Have you been able to get symbols for v8-x64.dll and ClearScriptV8-64.dll? Knowing what V8 was trying to do when it crashed could help identify a workaround.

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: We haven't as we thought the crashes were gone now. We'll try to get those up on the servers. We're using the 5.4.7 NuGet version if you manage to get the debug symbols for that before we get symbols up.

New Post: Code Caching

$
0
0
Hi,

Does ClearScript support code caching?

I am running v8 (using ClearScript and ReactJS.net) on asp.net and the first request takes about 10 second to run all the code and then subsequent requests takes about 200ms.

I profiled it and saw the v8 takes 90% of this 10 seconds, I suspect that if there is a way to expose v8 code caching I would able to build code cache on build time (using MSBuild step) and then later use the code cache.

Is this supported? and does it relates to: https://clearscript.codeplex.com/discussions/560532 ?

V8 Blog explains code caching: http://v8project.blogspot.co.il/2015/07/code-caching.html

New Post: Code Caching

$
0
0
Hello yosy,

ClearScript 5.4.8 (the next point release) will support V8 code caching.

Thanks!

Released: ClearScript 5.4 (Oct 22, 2014)

$
0
0
5.4.8
  • Added support for V8 parser and code caching.
  • Added ScriptObject to ease script object identification.
  • Fixed argument validation for interop interface parameters.
  • Fixed V8 crash when exceptions are thrown during script interruption (Issue #112).
  • Fixed V8 crash when code that consumes iterable host objects is optimized.
  • Fixed intermittent deadlocks during V8 runtime teardown.
  • Added a 64-bit OS check in V8Update.cmd.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 5.4.500.40.

5.4.7
  • Added ImmutableValueAttribute and fixed canonical reference support.
  • Hardened native timers and V8 background tasks, fixing intermittent V8 crashes.
  • Fixed nested V8 syntax error reporting.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 5.3.332.45.

5.4.6
  • Expanded canonical reference support to all equatable value types.
  • Fixed host-side and cross-engine assignment of VBScript class object properties (Issue #104).
  • Fixed a bug preventing assembly-qualified type names from being used with ScriptEngine.AddHostType().
  • Fixed double execution of exception-throwing code via C# dynamic (Issue #105).
  • Added IScriptEngineException.ExecutionStarted.
  • Fixed memory leak with shared V8 runtimes (Issue #107).
  • Fixed cross-engine double execution of exception-throwing code (Issue #108).
  • Tweaked V8 debug protocol implementation to support non-Eclipse debuggers.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 5.1.281.50.

5.4.5
  • Breaking Change: Added strongly-typed indexing support for IList<T>. Because IList<T> takes precedence over IList, array and list elements retrieved by index are now correctly type-restricted. Use the new propertyScriptEngine.DisableListIndexTypeRestriction to restore the previous behavior, orScriptEngine.DisableTypeRestriction to control type restriction globally.
  • Added V8ScriptEngine.SuppressExtensionMethodEnumeration (Issue #101).
  • Fixed native property hiding on V8 (Issue #98).
  • Fixed host method clobbering on V8.
  • Reduced V8 stack overflow detection false positives.
  • Added HostItemFlags.DirectAccess.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 4.9.385.30.

5.4.4
  • Added fast data transfer between host arrays and JavaScript typed arrays (and other ArrayBuffer views) (Issue #83).
  • IEnumerable instances now supportES6 iteration andfor...of when exposed inV8ScriptEngine.
  • Added fully dynamic treatment for exposed IDispatchEx instances (Issue #96).
  • Fixed host member enumeration and deletion on JScript with Standards Mode (Issue #94).
  • Improved numeric argument conversion and matching (Issue #95).
  • Fixed nested termination behavior on V8.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 4.7.80.25.

5.4.3
  • Added support for Visual Studio 2015.
  • Changed V8Update to use installed Python 2.x.
  • Fixed hangs in V8 proxy finalizers during script execution (Issue #86).
  • Fixed V8 weak handle callback context leak (Issue #90).
  • Fixed dynamic method invocation with value-typed arguments (Issue #89).
  • Improved V8ScriptEngine.Interrupt() latency and reliability.
  • Added tests for bug fixes.
  • Tested with V8 4.4.63.29.

5.4.2.1
  • Fixed unnecessary assembly table construction (Issue #84).

5.4.2
  • Updated ClearScriptBenchmarks to use SunSpider 1.0.2.
  • Host methods and delegates in V8ScriptEngine now supporttoFunction(), which creates a native JavaScript function wrapper.
  • Fixed syntax error reporting in nested WindowsScriptEngine invocations.
  • Added defensive code to tolerate IProcessDebugManager::AddApplication() failure (Issue #76).
  • Added ScriptEngine.AddHostType() overloads that derive the script item name from the type name.
  • Implemented host item data sharing and other optimizations, boosting memory efficiency in many scenarios.
  • Added default ScriptAccess settings at the type, assembly, and engine levels.
  • Enhanced support for default properties, fixing Issue #74.
  • Added IHostWindow and WindowsScriptEngine.HostWindow (Issue #73).
  • V8RuntimeConstraints limits are now specified inMiB. For compatibility with hosts that predate an inadvertent breaking change in Version 5.4.1, values greater than 1048576 (1TiB) are still interpreted as bytes.
  • Fixed V8 debug agent in ASP.NET and eliminated excessive thread usage (Issue #75).
  • Added ScriptMemberFlags.WrapNullResult, ScriptEngine.EnableNullResultWrapping, and HostFunctions.isNull() (Issue #72).
  • Added enforcement of restricted access to non-public accessors of public properties (Issue #71).
  • (Andrey Taritsyn) Switched assembly targets to .NET 4 Client Profile.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 4.2.77.18.

5.4.1
  • Fixed several issues affecting GlobalMembers on V8.
  • Implemented a V8 debug agent to compensate for removed V8 API.
  • V8Update now fetches V8 source and dependencies from Git repositories.
  • Fixed V8 assembly unloading and patched V8 to tolerate redundant initialization (Issue #60).
  • Added ScriptEngine.EnableAutoHostVariables.
  • Fixed by-reference arguments to VBScript functions (Issue #58).
  • Removed support for Visual Studio 2012 (V8 build now requires at least Visual Studio 2013).
  • Added explicit loading of primary interop assemblies to fix Issue #68.
  • Added host exception marshaling for V8.
  • Fixed V8ScriptEngine crash when script code calls theHostObject constructor.
  • Fixed host item caching for host variables.
  • Added non-generic overloads of newArr() andfunc() to HostFunctions.
  • Added ScriptEngine.Current.
  • HostFunctions instances can now be exposed in multiple script engines.
  • Added a GetDynamicMemberNames() override toMetaScriptItem (Issue #64).
  • Fixed indexed property binding ambiguity for inherited interfaces (Issue #69).
  • Added tests for bug fixes and new APIs.
  • Tested with V8 3.30.33.16.

5.4.0
  • Added COM object projection (Issue #38):
    • New ScriptEngine methods: AddCOMObject() and AddCOMType().
    • New ExtendedHostFunctions methods: newComObj() and comType().
  • Improved performance and memory usage:
    • Host methods, events, and const/readonly fields are now cached as direct V8 object properties.
    • Added shared bind cache for improved performance and enhanced binder leak mitigation.
    • Made V8ScriptEngine.CollectGarbage() much more aggressive.
    • Switched to weak context/isolate bindings for V8 script objects and compiled scripts, fixingIssue #44.
    • Bypassed reflection for Windows script item property and method access, fixingIssue #47.
    • Added explicit disposal of cached V8 objects to fix Issue #48.
  • Enhanced support for legacy scripts:
    • Added null, decimal, and array marshaling options to WindowsScriptEngine.
    • Added ScriptEngine.UseReflectionBindFallback.
    • VBScript's For Each ... Next and JScript's Enumerator now operate on IEnumerable instances.
  • Other enhancements:
    • Added optional heap size monitoring to V8ScriptEngine andV8Runtime (experimental).
    • Added HostFunctions.tryCatch().
    • Added ScriptEngine.Invoke() and V8ScriptEngine.Execute(V8Script).
    • Added ScriptEngine.DisableTypeRestriction.
    • Enhanced error reporting for V8 assembly load failures (Issue #39).
    • V8Update now supports branched V8 revisions.
  • Miscellaneous fixes:
    • Added a V8 array buffer all

Updated Release: ClearScript 5.4 (Oct 22, 2014)

$
0
0
5.4.8
  • Added support for V8 parser and code caching.
  • Added ScriptObject to ease script object identification.
  • Fixed argument validation for interop interface parameters.
  • Fixed V8 crash when exceptions are thrown during script interruption (Issue #112).
  • Fixed V8 crash when code that consumes iterable host objects is optimized.
  • Fixed intermittent deadlocks during V8 runtime teardown.
  • Added a 64-bit OS check in V8Update.cmd.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 5.4.500.40.

5.4.7
  • Added ImmutableValueAttribute and fixed canonical reference support.
  • Hardened native timers and V8 background tasks, fixing intermittent V8 crashes.
  • Fixed nested V8 syntax error reporting.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 5.3.332.45.

5.4.6
  • Expanded canonical reference support to all equatable value types.
  • Fixed host-side and cross-engine assignment of VBScript class object properties (Issue #104).
  • Fixed a bug preventing assembly-qualified type names from being used with ScriptEngine.AddHostType().
  • Fixed double execution of exception-throwing code via C# dynamic (Issue #105).
  • Added IScriptEngineException.ExecutionStarted.
  • Fixed memory leak with shared V8 runtimes (Issue #107).
  • Fixed cross-engine double execution of exception-throwing code (Issue #108).
  • Tweaked V8 debug protocol implementation to support non-Eclipse debuggers.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 5.1.281.50.

5.4.5
  • Breaking Change: Added strongly-typed indexing support for IList<T>. Because IList<T> takes precedence over IList, array and list elements retrieved by index are now correctly type-restricted. Use the new property ScriptEngine.DisableListIndexTypeRestriction to restore the previous behavior, or ScriptEngine.DisableTypeRestriction to control type restriction globally.
  • Added V8ScriptEngine.SuppressExtensionMethodEnumeration (Issue #101).
  • Fixed native property hiding on V8 (Issue #98).
  • Fixed host method clobbering on V8.
  • Reduced V8 stack overflow detection false positives.
  • Added HostItemFlags.DirectAccess.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 4.9.385.30.

5.4.4
  • Added fast data transfer between host arrays and JavaScript typed arrays (and other ArrayBuffer views) (Issue #83).
  • IEnumerable instances now support ES6 iteration and for...of when exposed in V8ScriptEngine.
  • Added fully dynamic treatment for exposed IDispatchEx instances (Issue #96).
  • Fixed host member enumeration and deletion on JScript with Standards Mode (Issue #94).
  • Improved numeric argument conversion and matching (Issue #95).
  • Fixed nested termination behavior on V8.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 4.7.80.25.

5.4.3
  • Added support for Visual Studio 2015.
  • Changed V8Update to use installed Python 2.x.
  • Fixed hangs in V8 proxy finalizers during script execution (Issue #86).
  • Fixed V8 weak handle callback context leak (Issue #90).
  • Fixed dynamic method invocation with value-typed arguments (Issue #89).
  • Improved V8ScriptEngine.Interrupt() latency and reliability.
  • Added tests for bug fixes.
  • Tested with V8 4.4.63.29.

5.4.2.1
  • Fixed unnecessary assembly table construction (Issue #84).

5.4.2
  • Updated ClearScriptBenchmarks to use SunSpider 1.0.2.
  • Host methods and delegates in V8ScriptEngine now support toFunction(), which creates a native JavaScript function wrapper.
  • Fixed syntax error reporting in nested WindowsScriptEngine invocations.
  • Added defensive code to tolerate IProcessDebugManager::AddApplication() failure (Issue #76).
  • Added ScriptEngine.AddHostType() overloads that derive the script item name from the type name.
  • Implemented host item data sharing and other optimizations, boosting memory efficiency in many scenarios.
  • Added default ScriptAccess settings at the type, assembly, and engine levels.
  • Enhanced support for default properties, fixing Issue #74.
  • Added IHostWindow and WindowsScriptEngine.HostWindow (Issue #73).
  • V8RuntimeConstraints limits are now specified in MiB. For compatibility with hosts that predate an inadvertent breaking change in Version 5.4.1, values greater than 1048576 (1 TiB) are still interpreted as bytes.
  • Fixed V8 debug agent in ASP.NET and eliminated excessive thread usage (Issue #75).
  • Added ScriptMemberFlags.WrapNullResult, ScriptEngine.EnableNullResultWrapping, and HostFunctions.isNull() (Issue #72).
  • Added enforcement of restricted access to non-public accessors of public properties (Issue #71).
  • (Andrey Taritsyn) Switched assembly targets to .NET 4 Client Profile.
  • Added tests for bug fixes and new APIs.
  • Tested with V8 4.2.77.18.

5.4.1
  • Fixed several issues affecting GlobalMembers on V8.
  • Implemented a V8 debug agent to compensate for removed V8 API.
  • V8Update now fetches V8 source and dependencies from Git repositories.
  • Fixed V8 assembly unloading and patched V8 to tolerate redundant initialization (Issue #60).
  • Added ScriptEngine.EnableAutoHostVariables.
  • Fixed by-reference arguments to VBScript functions (Issue #58).
  • Removed support for Visual Studio 2012 (V8 build now requires at least Visual Studio 2013).
  • Added explicit loading of primary interop assemblies to fix Issue #68.
  • Added host exception marshaling for V8.
  • Fixed V8ScriptEngine crash when script code calls the HostObject constructor.
  • Fixed host item caching for host variables.
  • Added non-generic overloads of newArr() and func() to HostFunctions.
  • Added ScriptEngine.Current.
  • HostFunctions instances can now be exposed in multiple script engines.
  • Added a GetDynamicMemberNames() override to MetaScriptItem (Issue #64).
  • Fixed indexed property binding ambiguity for inherited interfaces (Issue #69).
  • Added tests for bug fixes and new APIs.
  • Tested with V8 3.30.33.16.

5.4.0
  • Added COM object projection (Issue #38):
    • New ScriptEngine methods: AddCOMObject() and AddCOMType().
    • New ExtendedHostFunctions methods: newComObj() and comType().
  • Improved performance and memory usage:
    • Host methods, events, and const/readonly fields are now cached as direct V8 object properties.
    • Added shared bind cache for improved performance and enhanced binder leak mitigation.
    • Made V8ScriptEngine.CollectGarbage() much more aggressive.
    • Switched to weak context/isolate bindings for V8 script objects and compiled scripts, fixing Issue #44.
    • Bypassed reflection for Windows script item property and method access, fixing Issue #47.
    • Added explicit disposal of cached V8 objects to fix Issue #48.
  • Enhanced support for legacy scripts:
    • Added null, decimal, and array marshaling options to WindowsScriptEngine.
    • Added ScriptEngine.UseReflectionBindFallback.
    • VBScript's For Each ... Next and JScript's Enumerator now operate on IEnumerable instances.
  • Other enhancements:
    • Added optional heap size monitoring to V8ScriptEngine and V8Runtime (experimental).
    • Added HostFunctions.tryCatch().
    • Added ScriptEngine.Invoke() and V8ScriptEngine.Execute(V8Script).
    • Added ScriptEngine.DisableTypeRestriction.
    • Enhanced error reporting for V8 assembly load failures (Issue #39).
    • V8Update now supports branched V8 revisions.
  • Miscellaneous fixes:
    • Added a V8 array buffer all

Updated Wiki: Documentation

$
0
0

Documentation

To learn more about ClearScript:
  • Check out the ClearScript tutorial: [Word], [PDF].
  • Browse the ClearScript Library Reference: [Reference.chm]. Save this file before opening it. If you get a security warning when you open it, uncheck "Always ask before opening this file".
  • View the latest information in the ClearScript ReadMe.
  • Take a look at our latest Announcements.

Updated Wiki: Announcements

$
0
0

11/2/2016: Version 5.4.8 released.

View the release notes and download the source code here. Note: Because of changes in V8 5.4, the V8Update script now requires a 64-bit operating system. Once built, ClearScript can still be deployed in a 32-bit environment. See the ClearScript ReadMe for the latest information.

9/13/2016: Version 5.4.7 released.

View the release notes and download the source code here.

5/29/2016: Version 5.4.6 released.

View the release notes and download the source code here.

3/10/2016: Version 5.4.5 released.

View the release notes and download the source code here.

12/8/2015: Version 5.4.4 released.

View the release notes and download the source code here.

8/17/2015: Version 5.4.3 released.

View the release notes and download the source code here. Note: This release adds support for Visual Studio 2015 and updates the procedure for downloading and building V8. See the ClearScript ReadMe for the latest information.

6/30/2015: Version 5.4.2.1 released.

View the release notes and download the source code here. This is a bug fix release only.

5/10/2015: Version 5.4.2 released.

View the release notes and download the source code here.

2/8/2015: Version 5.4.1 released.

View the release notes and download the source code here. Note: This release removes support for Visual Studio 2012 and updates the procedure for downloading and building V8. See the ClearScript ReadMe for the latest information.

10/22/2014: ClearScript 5.4 released.

View the release notes and download the source code here.

1/16/2014: Version 5.3.11 released.

View the release notes and download the source code here.

11/28/2013: Version 5.3.10 released.

View the release notes and download the source code here.

10/29/2013: Version 5.3.9 released.

View the release notes and download the source code here.

10/14/2013: Version 5.3.8 released.

View the release notes and download the source code here.

8/22/2013: Version 5.3.7 released.

View the release notes and download the source code here.

8/14/2013: Version 5.3.6 released.

View the release notes and download the source code here.

8/2/2013: Version 5.3.5 released.

View the release notes and download the source code here.

7/10/2013: Version 5.3.4 released.

View the release notes and download the source code here.

7/2/2013: Version 5.3.3 released.

View the release notes and download the source code here.

6/6/2013: Version 5.3.2 released.

View the release notes and download the source code here. Due to issues with several recent V8 trunk releases (build failures, breaking API changes, etc.), and because more breaking changes are coming soon, this release modifies V8Update so that it fetches a tested, known-good V8 revision by default. See the ClearScript ReadMe for more information.

5/31/2013: Version 5.3.1 released.

View the release notes and download the source code here.

5/21/2013: ClearScript 5.3 released.

View the release notes and download the source code here.

5/15/2013: Version 5.2.2 released.

View the release notes and download the source code here. This release addresses the build issue reported yesterday and can be used with the latest V8 version. Here's how to update your copy of V8:
C:\ClearScript> set V8REV=
C:\ClearScript> V8Update

5/14/2013: ClearScript build failure due to API deprecation in V8 3.19.1.

We are aware of a ClearScript build issue with the latest version of V8. Until this issue is resolved we recommend that you explicitly use V8 3.19.0:
C:\ClearScript> set V8REV=14604
C:\ClearScript> V8Update

5/2/2013: Version 5.2.1 released.

View the release notes and download the source code here.

4/18/2013: V8Update failure resolved by V8 3.18.1.

The V8Update issue reported yesterday has been fixed by a new version of V8 released today. Here's how to update to the latest V8 version:
C:\ClearScript> set V8REV=
C:\ClearScript> V8Update

4/17/2013: V8Update failure with V8 3.18.0.

We are aware of a V8Update issue with the latest version of V8. Until this issue is resolved we recommend that you explicitly use V8 3.17.16:
C:\ClearScript> set V8REV=14138
C:\ClearScript> V8Update

3/27/2013: ClearScript 5.2 released.

View the release notes and download the source code here.

3/8/2013: Version 5.1.3 released.

View the release notes and download the source code here.

3/4/2013: V8Update failure resolved by V8 3.17.7.

The V8Update issue reported earlier has been fixed by a new version of V8 released today. Here's how to update to the latest V8 version:
C:\ClearScript> set V8REV=
C:\ClearScript> V8Update

3/4/2013: V8Update failure with V8 3.17.6.

We are aware of a V8Update issue with the latest version of V8. The issue affects the "Building 64-bit V8" step. The V8 team appears to have already submitted a fix, but the fix has not yet been merged into the trunk. In the meantime, we recommend that you explicitly use V8 3.17.5:
C:\ClearScript> set V8REV=13745
C:\ClearScript> V8Update

Updated Wiki: Home

$
0
0
InfoIcon.jpgVersion 5.4.8 released. More...

Description

ClearScript is a library that makes it easy to add scripting to your .NET applications. It currently supports JavaScript (via V8 and JScript) and VBScript.

Features

  • Simple usage; create a script engine, add your objects and/or types, run scripts
  • Support for several script engines: Google's V8, Microsoft's JScript and VBScript
  • Exposed resources require no modification, decoration, or special coding of any kind
  • Scripts get simple access to most of the features of exposed objects and types:
    • Methods, properties, fields, events
    • (Objects) Indexers, extension methods, conversion operators, explicitly implemented interfaces
    • (Types) Constructors, nested types
  • Full support for generic types and methods, including C#-like type inference and explicit type arguments
  • Scripts can invoke methods with output parameters, optional parameters, and parameter arrays
  • Script delegates enable callbacks into script code
  • Support for exposing all the types defined in one or more assemblies in one step
  • Optional support for importing types and assemblies from script code
  • The host can invoke script functions and access script objects directly
  • Full support for script debugging

Examples

using System;
using Microsoft.ClearScript;
using Microsoft.ClearScript.JavaScript;
using Microsoft.ClearScript.V8;

// create a script engineusing (var engine = new V8ScriptEngine())
{
    // expose a host type
    engine.AddHostType("Console", typeof(Console));
    engine.Execute("Console.WriteLine('{0} is an interesting number.', Math.PI)");

    // expose a host object
    engine.AddHostObject("random", new Random());
    engine.Execute("Console.WriteLine(random.NextDouble())");

    // expose entire assemblies
    engine.AddHostObject("lib", new HostTypeCollection("mscorlib", "System.Core"));
    engine.Execute("Console.WriteLine(lib.System.DateTime.Now)");

    // create a host object from script
    engine.Execute(@"
        birthday = new lib.System.DateTime(2007, 5, 22);
        Console.WriteLine(birthday.ToLongDateString());
    ");

    // use a generic class from script
    engine.Execute(@"
        Dictionary = lib.System.Collections.Generic.Dictionary;
        dict = new Dictionary(lib.System.String, lib.System.Int32);
        dict.Add('foo', 123);
    ");

    // call a host method with an output parameter
    engine.AddHostObject("host", new HostFunctions());
    engine.Execute(@"
        intVar = host.newVar(lib.System.Int32);
        found = dict.TryGetValue('foo', intVar.out);
        Console.WriteLine('{0} {1}', found, intVar);
    ");

    // create and populate a host array
    engine.Execute(@"
        numbers = host.newArr(lib.System.Int32, 20);
        for (var i = 0; i < numbers.Length; i++) { numbers[i] = i; }
        Console.WriteLine(lib.System.String.Join(', ', numbers));
    ");

    // create a script delegate
    engine.Execute(@"
        Filter = lib.System.Func(lib.System.Int32, lib.System.Boolean);
        oddFilter = new Filter(function(value) {
            return (value & 1) ? true : false;
        });
    ");

    // use LINQ from script
    engine.Execute(@"
        oddNumbers = numbers.Where(oddFilter);
        Console.WriteLine(lib.System.String.Join(', ', oddNumbers));
    ");

    // use a dynamic host object
    engine.Execute(@"
        expando = new lib.System.Dynamic.ExpandoObject();
        expando.foo = 123;
        expando.bar = 'qux';
        delete expando.foo;
    ");

    // call a script function
    engine.Execute("function print(x) { Console.WriteLine(x); }");
    engine.Script.print(DateTime.Now.DayOfWeek);

    // examine a script object
    engine.Execute("person = { name: 'Fred', age: 5 }");
    Console.WriteLine(engine.Script.person.name);

    // read a JavaScript typed array
    engine.Execute("values = new Int32Array([1, 2, 3, 4, 5])");
    var values = (ITypedArray<int>)engine.Script.values;
    Console.WriteLine(string.Join(", ", values.ToArray()));
}

New Post: V8 Null Pointer crash when using "for (let a of hostObj)"


New Post: Code Caching

$
0
0
Hi again,

ClearScript 5.4.8 is now available.

Good luck!

New Post: Serializing a compiled script

$
0
0
Hi Uniphix,

ClearScript 5.4.8 supports V8 caching, although serialization of the cache data remains the host's responsibility.

Cheers!

Edited Issue: [BUG] Crash when calling Interrupt() at bad time [112]

$
0
0
Hello,

we are having issues with a portion of code that basically provokes an exception in user code called by clearscript, and then calls Interrupt on the V8 engine.

It always crashes. Isn't this scenario supposed to function properly ? (I mean, Interrupt should not crash... ?)

Should I explicitely wait before Interrupting in this case ? (but this would be some sort of workaround?)

Cdlt,
Julien.

btw: reproduced on ClearScript 5.4.6 (Nuget version)

```
[Test]
public virtual void TestScriptTerminateCrash()
{
var ctx = new PropertyBag();
using (var engine = new V8ScriptEngine("CrashScript"))
{
engine.AddHostObject("context", ctx);

var eventW = new ManualResetEventSlim(initialState: false);
var tokenSource = new CancellationTokenSource();

// start notification only
var startEvent = new ManualResetEventSlim(false);

ThreadStart main = () =>
{
try
{

ctx["waitCode"] = new Action(() =>
{
// Waiting in the C# code : a cancel exception is generated here
eventW.Wait(tokenSource.Token);

});
ctx["startEvent"] = startEvent;
ctx["counter"] = 0;
try
{
System.DateTime dtRun = System.DateTime.UtcNow;
engine.Execute("dummyDocument.js", @"
// Start
context.counter = 1;

context.startEvent.Set();

context.counter = 2;

context.waitCode();

context.counter = 3;


");
Assert.Inconclusive();
}
catch (Microsoft.ClearScript.ScriptInterruptedException si)
{
Assert.That(si.Message.Contains("interrupted"));
}
catch (Microsoft.ClearScript.ScriptEngineException segx)
{
if (segx.InnerException is System.Reflection.TargetInvocationException &&
segx.InnerException.InnerException != null)
throw segx.InnerException.InnerException;
Assert.Fail();
}
}
catch (OperationCanceledException)
{
}
catch (Exception)
{
Assert.Fail();
}

};

var t = new Thread(main);
t.Start();
Assert.That(startEvent.Wait(5000));

// Cancel + interrupt
tokenSource.Cancel();
//Thread.Sleep(1000); // won't fail if we interrupt later
engine.Interrupt();

t.Join();

Assert.AreEqual(2, (Int32)ctx["counter"]);
}
}

```

Commented Issue: [BUG] Crash when calling Interrupt() at bad time [112]

$
0
0
Hello,

we are having issues with a portion of code that basically provokes an exception in user code called by clearscript, and then calls Interrupt on the V8 engine.

It always crashes. Isn't this scenario supposed to function properly ? (I mean, Interrupt should not crash... ?)

Should I explicitely wait before Interrupting in this case ? (but this would be some sort of workaround?)

Cdlt,
Julien.

btw: reproduced on ClearScript 5.4.6 (Nuget version)

```
[Test]
public virtual void TestScriptTerminateCrash()
{
var ctx = new PropertyBag();
using (var engine = new V8ScriptEngine("CrashScript"))
{
engine.AddHostObject("context", ctx);

var eventW = new ManualResetEventSlim(initialState: false);
var tokenSource = new CancellationTokenSource();

// start notification only
var startEvent = new ManualResetEventSlim(false);

ThreadStart main = () =>
{
try
{

ctx["waitCode"] = new Action(() =>
{
// Waiting in the C# code : a cancel exception is generated here
eventW.Wait(tokenSource.Token);

});
ctx["startEvent"] = startEvent;
ctx["counter"] = 0;
try
{
System.DateTime dtRun = System.DateTime.UtcNow;
engine.Execute("dummyDocument.js", @"
// Start
context.counter = 1;

context.startEvent.Set();

context.counter = 2;

context.waitCode();

context.counter = 3;


");
Assert.Inconclusive();
}
catch (Microsoft.ClearScript.ScriptInterruptedException si)
{
Assert.That(si.Message.Contains("interrupted"));
}
catch (Microsoft.ClearScript.ScriptEngineException segx)
{
if (segx.InnerException is System.Reflection.TargetInvocationException &&
segx.InnerException.InnerException != null)
throw segx.InnerException.InnerException;
Assert.Fail();
}
}
catch (OperationCanceledException)
{
}
catch (Exception)
{
Assert.Fail();
}

};

var t = new Thread(main);
t.Start();
Assert.That(startEvent.Wait(5000));

// Cancel + interrupt
tokenSource.Cancel();
//Thread.Sleep(1000); // won't fail if we interrupt later
engine.Interrupt();

t.Join();

Assert.AreEqual(2, (Int32)ctx["counter"]);
}
}

```

Comments: Fixed in [Version 5.4.8](https://clearscript.codeplex.com/SourceControl/changeset/5ebc1dda8f1678cc5985e0942ac340c535d320de).

Commented Unassigned: Access Violation Exception in v8-x64.dll [115]

$
0
0
Hi!
We launched a new site last week that uses ClearScript to server render a React application. After launch, we get around 2-3 crashes on Access Violation Exception in w3wp.exe a day per web server. The site has around 200 concurrent users on average, with peaks up over a thousand. We use the latest version of ClearScript (5.4.7).

We see that the crash is an Access Violation Exception in v8-x64.dll and we have a few dump files from such crashes, but since we don't have any debugging symbols the stack traces doesn't give us much.

Would you be interested in looking at the crash dumps to help us figure this out? Or if you can help us with debug symbols so we can get more information out of the dumps.

Some information about how we use ClearScript:
1. We create multiple V8Runtime and V8ScriptEngine and keep them in a queue. When a request comes in, we dequeue an engine, run JS and return it back to the queue.
2. Since we don't store any JS globals we reuse the same V8 context for different visitors. But we run CollectGarbage(true) for every 30 execution. We have deployed a change this morning where we call CollectGarbage(false) instead but twice as often. Not because we think it will solve it, but see if the behavior changes.
3. We don't pass any CLR references to V8. The only thing we do is call Engine.Execute with strings of JS code. When we pass data to V8 we do that by either calling Engine.Execute or Engine.Evaluate with strings of JSON.

Any help or pointers are appreciated! We'd be happy to share code with you if you need it.
Comments: Please consider updating to ClearScript 5.4.8, which is paired with a newer version of V8. In the meantime, since we can't reproduce the crash and we haven't received any new information over the last two weeks, we're closing this issue.
Viewing all 2297 articles
Browse latest View live


Latest Images