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

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.

Viewing all articles
Browse latest Browse all 2297

Latest Images

Trending Articles





Latest Images