Segfault when creating second rust MainWorker in program
Hello.
Not sure if this is the place to ask since it seems to be a v8 issue (or perhaps an issue with the bindings), but I figured at least people here can point me in the right direction.
I have a segfault issue after updating deno_runtime from 0.122.0 to 0.131.0 (deno_core 0.199.0 to 0.229.0). My program segfaults when starting a second worker after the first one has completed, and on a different thread.
Running in valgrind it doesn't crash, but it does print a few
==419765== Warning: set address range perms: large range [0x120f7000, 0x32136000) (noaccess)
, but as far as I can figure out this is just a log for valgrind developers.
Using gdb with a core dump I narrowed down the issue to v8::internal::Heap::SetUpSpaces(v8::internal::LinearAllocationArea&, v8::internal::LinearAllocationArea&)
, but I'm wondering if I'm doing something wrong to be hitting this issue, or if someone else has encountered this. IIRC the last few versions of deno_core have the same v8 version (0.81.0), so it seems strange that nobody encountered this before if I'm doing everything right.
I have a minimal reproducible example here: https://github.com/primoze/set-up-spaces
I haven't found anything regarding SetUpSpaces
searching online, so I thought I'd ask here.GitHub
GitHub - primoze/set-up-spaces: Minimal reproducible example for de...
Minimal reproducible example for deno/v8 segfault. Contribute to primoze/set-up-spaces development by creating an account on GitHub.
9 Replies
I'm sorry to hear that you're experiencing a segfault issue. Based on the documentation, Deno does support the use of Workers, which can be used to run code on multiple threads. Each instance of
Worker
is run on a separate thread, dedicated only to that worker. However, there are some specific ways to create a worker in Deno.
Here is the recommended way to create a worker:
And here are some examples that are not recommended:
If you're not creating the workers in the recommended way, this could potentially be causing the issue.
Also, it's important to note that Workers currently do not work in compiled executables. If you're trying to use Workers in a compiled executable, this could be the source of the problem.
If you're still experiencing the issue after checking these points, it might be helpful to debug the issue further. Deno has built-in debugger capabilities that make it possible to use remote debuggers like Chrome Devtools or the VSCode builtin debugger. These tools can be extremely useful when trying to pin-point bugs.
If you're still unable to resolve the issue, it might be best to open an issue on the Deno GitHub repository to get help from the Deno community. 🦕My problem is not caused by JS workers, but by
deno_runtime::workers::MainWorker
being initialized in rust code.
It'd be great if a human could take a look at this...
The issue starts occurring when upgrading from 0.129.0 to 0.130.0 (v8 0.79,2 to 0.81.0)hi, I have a reproduction repo that may be related, if I reload a module it segfaults if I keep a reference to the worker but it doesn't if I don't. The repo is here:
https://github.com/marianoguerra-atik/deno-runtime-segfault
GitHub
GitHub - marianoguerra-atik/deno-runtime-segfault: reproduction of ...
reproduction of issue. Contribute to marianoguerra-atik/deno-runtime-segfault development by creating an account on GitHub.
the runtime folks hang out more in #dev-core or #dev-rusty_v8 than here
Note: since V8 11.6, all runtimes must have a common parent thread that initalized the V8 platform.
this solved the issue, but as far as I can tell there are versions with v8 > 11.6 which don't have the issue@primoze how do you initialize v8?
this is just from the example at https://docs.rs/v8/latest/v8/
v8 - Rust
Example
i need to read up on Platform
also this only solves the issue in my repro example, in my actual app it segfaults even earlier now, when creating the first worker. maybe the issue is that i initialize the plaform in tokio::main (so inside a runtime), i need to shuffle some code around and so that it doesn't happen inside a runtime and see if it works
yup, that was the issue