Hi everybody,
I just noticed a behavior that differs between ClearScript v 5.3.9 and 5.3.10, and it's about limiting memory for a script execution. Consider following faulty script (it emulates a memory leak) being executed inside the 64 bit console application:
```
var sample_arr = [-1, 5, 7, 4, 0, 1, -5]
function My_Partition(container, first_index, last_index) {
var x = container[last_index];
var i = first_index - 1;
for (var elem = 0; elem < container.length-1; elem++) {
if (container[elem] <= x) {
i += 1;
var temp_1 = container[i];
container[i] = container[elem];
container[elem] = temp_1;
}
}
var temp_2 = container[i+1];
container[i+1] = container[last_index];
container[last_index] = temp_2;
return i+1;
}
function My_Quick_Sort(container, first_index, last_index) {
if (first_index < last_index) {
var mid = My_Partition(container, first_index, last_index);
My_Quick_Sort(container, first_index, mid-1);
My_Quick_Sort(container, mid+1, last_index);
}
}
My_Quick_Sort(sample_arr, 0, sample_arr.length-1);
console.WriteLine("Sorted Array:", sample_arr);
```
as well as following ClearScript's V8 engine configuration:
```
Using engine As New V8ScriptEngine("V8Engine", New V8RuntimeConstraints() With {.MaxOldSpaceSize = 209715200}, V8ScriptEngineFlags.EnableDebugging, 9222)
```
You'll notice that after running above code in 5.3.9 it gracefully ends up with an exception that indicates a memory limit being exceeded (see attachment). However, in 5.3.10 it doesn't result in exception and rather hard-crashes with a message in the console (see attachment). Could you test it on your end and provide some follow-up?
System used for testing: Window 7, 64 bit.
Thanks for your work,
Max
Comments: Update: The V8 developers have doubled down on their position that even artificial out-of-memory and stack overflow conditions warrant process termination, and that the sandboxing APIs they published earlier were a mistake. Their rationale is that clean recovery from these conditions is impossible without costly checks, and since Chrome's multi-process architecture withstands tab crashes, they're not willing to pay that price. Our [bug report](https://code.google.com/p/v8/issues/detail?id=3060) triggered a clarification of the team's policy: "I can understand that there are scenarios outside of Chrome where a slower execution handling OOM more gracefully would be preferable, but this is outside v8's scope." Over the last several months we've been trying to identify a safe, reliable, and durable workaround. A big problem is that, in addition to tangible resource constraints, V8 raises fatal errors when it exceeds various internal limits that the host cannot control or monitor. Therefore we've decided to abandon the search for a way to block V8 crashes. ClearScript will retain APIs such as `V8RuntimeConstraints` and `MaxRuntimeStackUsage`, but they will now function like the corresponding V8 APIs do; that is, they will not prevent process termination. We apologize for any inconvenience this causes ClearScript users.
I just noticed a behavior that differs between ClearScript v 5.3.9 and 5.3.10, and it's about limiting memory for a script execution. Consider following faulty script (it emulates a memory leak) being executed inside the 64 bit console application:
```
var sample_arr = [-1, 5, 7, 4, 0, 1, -5]
function My_Partition(container, first_index, last_index) {
var x = container[last_index];
var i = first_index - 1;
for (var elem = 0; elem < container.length-1; elem++) {
if (container[elem] <= x) {
i += 1;
var temp_1 = container[i];
container[i] = container[elem];
container[elem] = temp_1;
}
}
var temp_2 = container[i+1];
container[i+1] = container[last_index];
container[last_index] = temp_2;
return i+1;
}
function My_Quick_Sort(container, first_index, last_index) {
if (first_index < last_index) {
var mid = My_Partition(container, first_index, last_index);
My_Quick_Sort(container, first_index, mid-1);
My_Quick_Sort(container, mid+1, last_index);
}
}
My_Quick_Sort(sample_arr, 0, sample_arr.length-1);
console.WriteLine("Sorted Array:", sample_arr);
```
as well as following ClearScript's V8 engine configuration:
```
Using engine As New V8ScriptEngine("V8Engine", New V8RuntimeConstraints() With {.MaxOldSpaceSize = 209715200}, V8ScriptEngineFlags.EnableDebugging, 9222)
```
You'll notice that after running above code in 5.3.9 it gracefully ends up with an exception that indicates a memory limit being exceeded (see attachment). However, in 5.3.10 it doesn't result in exception and rather hard-crashes with a message in the console (see attachment). Could you test it on your end and provide some follow-up?
System used for testing: Window 7, 64 bit.
Thanks for your work,
Max
Comments: Update: The V8 developers have doubled down on their position that even artificial out-of-memory and stack overflow conditions warrant process termination, and that the sandboxing APIs they published earlier were a mistake. Their rationale is that clean recovery from these conditions is impossible without costly checks, and since Chrome's multi-process architecture withstands tab crashes, they're not willing to pay that price. Our [bug report](https://code.google.com/p/v8/issues/detail?id=3060) triggered a clarification of the team's policy: "I can understand that there are scenarios outside of Chrome where a slower execution handling OOM more gracefully would be preferable, but this is outside v8's scope." Over the last several months we've been trying to identify a safe, reliable, and durable workaround. A big problem is that, in addition to tangible resource constraints, V8 raises fatal errors when it exceeds various internal limits that the host cannot control or monitor. Therefore we've decided to abandon the search for a way to block V8 crashes. ClearScript will retain APIs such as `V8RuntimeConstraints` and `MaxRuntimeStackUsage`, but they will now function like the corresponding V8 APIs do; that is, they will not prevent process termination. We apologize for any inconvenience this causes ClearScript users.