Script::compile sometimes throw maximum call stack size exceeded

[abnud1]

I'm compiling javascript expression that resolves to function using the regular Script::compile and then run it.

Most of the times it works as expected, no error is thrown

But sometimes Script::compile returns none, by wrapping script running with try-catch I could identify the error that happens which is : Uncaught RangeError: Maximum call stack size exceeded

I don't have any recursion in the javascript expression and besides the same expression works sometimes and sometimes it throws the above error.

So what is happening ? Am I doing something wrong in configuring V8 ? the isolate is created with Default;:default() create params

[ry]

Can you provide example code that demonstrates this?

[abnud1]

let platform = v8::new_default_platform().unwrap();
v8::V8::initialize_platform(platform);
v8::V8::initialize();

let isolate = &mut v8::Isolate::new(Default::default());

let scope = &mut v8::HandleScope::new(isolate);
let context = v8::Context::new(scope);
let scope = &mut v8::ContextScope::new(scope, context);

let code = v8::String::new(scope, "this.test={default: () => 2}").unwrap();
let mut script = v8::Script::compile(scope, code, None).unwrap();
script.run(scope).unwrap();

let code = v8::String::new(scope, "test").unwrap();
let mut script = v8::Script::compile(scope, code, None).unwrap(); // <----- this is the line at which the RangeError is thrown
let result = script.run(scope).unwrap();

[abnud1]

The js error is thrown after multiple executions of the second script

[abnud1]

on second thought it happens just randomly which is annoying but true

[bnoordhuis]

On what arch+os combo does this happen? What happens when you pass --stack_size=<kb> to V8? You pass flags by calling V8::set_flags_from_string() or V8::set_flags_from_command_line() first thing.

Caveat emptor: --stack_size=<kb> does not change the stack size, like you'd maybe expect, it tells V8 to assume it's that many kilobytes big.

Oh, and if you're using threads + musl libc, keep in mind that musl by default creates threads with really tiny stacks, on the order of 80 kB (vs. 2-4 MB with glibc.)

[abnud1]

Windows 10 x64, I'll try passing --stack-size

[bnoordhuis]

Threads on Windows generally have smaller stacks than on Linux and macOS. Try a value of 900 or thereabouts.

[abnud1]

@bnoordhuis increasing stack size didn't help unfortunately

[abnud1]

oh I forgot to mention that once the error is thrown I can't execute any scripts until I restart the whole application

[bnoordhuis]

I'm afraid I don't have any hints or suggestions. I can't reproduce on Linux and I don't have a Windows machine at hand.

[abnud1]

@bnoordhuis I forgot to mention that my application is multi-threaded, I ensure that only one thread may access an isolate at a time but multiple threads access the same isolate on different times, is that the problem ?

[bnoordhuis]

I suspect that is indeed problematic at the moment. V8 has v8::Locker to manage its thread-local state but rusty_v8 doesn't currently use or expose that. That probably explains the erratic behavior you're seeing.

@piscisaureus You've probably thought about this issue before. Ideas?

[piscisaureus]

@piscisaureus You've probably thought about this issue before. Ideas?

It seems that Locker does park/unpark some thread specific state so that could be it.

rusty_v8 did have Locker at some point but its removal was forced through by someone else, who one day got very upset that function calls were involved and those could be observed with dtrace.

[bnoordhuis]

For reference, that was PR #272.

[devsnek]

We will track this in #486.

[robinehrlich]

I encountered the same problem on Windows. By increasing the stack size from the Visual Studio default of 1MB to 2MB and adding "isolate->SetStackLimit(2 * 1024 * 1024)" the problem went away.