Initializing two workers causes a seg-fault

[kdumontnu]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:
Running the following script:

use rustyscript::{worker::DefaultWorker, Error, Module};

fn main() -> Result<(), Error> {
    let worker = DefaultWorker::new(Default::default())?;
    let worker2 = DefaultWorker::new(Default::default())?;

    let module = Module::new("test.js", "export function add(a, b) { return a + b; }");
    let module_id = worker.load_module(module)?;

    let result: i32 =
        worker.call_function(Some(module_id), "add".to_string(), vec![1.into(), 2.into()])?;
    println!("{}", result);
    Ok(())
}

Causes a seg fault. I ran into this issue when trying to run on multiple threads (see here)

Desktop (please complete the following information):

• OS: Linux
• rustyscript = "0.8.3"

Additional context
Add any other context about the problem here.

[utyfua]

Did you try to call rustyscript::utilities::init_platform? #213 (comment)

Also whenever you destroy created runtimes, you must be sure to drop them newest-to-oldest. #224

[rscarson]

Did you try to call rustyscript::utilities::init_platform? #213 (comment)

Also whenever you destroy created runtimes, you must be sure to drop them newest-to-oldest. #224

Workers already call it by default
And the drop-order is only an intra-thread requirement

[rscarson]

I am having trouble reproducing the crash on Windows or Linux

In your discussion post you mention the segfault happens on the 2nd call

It crashes on the first call for you in this sample?

[kdumontnu]

It runs fine with let worker2 = DefaultWorker::new(Default::default())?; commented out, but seg-faults with it inline.

Is there any other context that would help to understand from my instance?

[rscarson]

Interesting

Can you debug to find out exactly where it crashes?

[kovaszab]

I suspect it could be solved by utilizing snapshots of the workers runtimes. I got similiar segfault error when tried to run 2 runtimes on separate threads. Debugging showed that internally the two runtimes used the same memory map for their v8 engines, causing segfault. Fixed it via creating snapshots of the runtimes, which made them reference their own memory map not a global one. Might wortth a try in your usecase too.

[kdumontnu]

I suspect it could be solved by utilizing snapshots of the workers runtimes. I got similiar segfault error when tried to run 2 runtimes on separate threads. Debugging showed that internally the two runtimes used the same memory map for their v8 engines, causing segfault. Fixed it via creating snapshots of the runtimes, which made them reference their own memory map not a global one. Might wortth a try in your usecase too.

Thanks! Do you have a code snippet you can link to? Might be worth updating in rustyscript examples.

[kovaszab]

You can have a look at 'create_snapshot.rs' example, basically in my case I created 2 separate runtimes, created snapshots (for each of them becase they used different extensions) and then loaded them in separate threads. I think in your case, I'd create a runtime, snapshot it, and then initialize 2 workers with copies of the runtime snapshots. I could provide you a minimal example when I'll have time, in case you get stuck

[rscarson]

Just out of curiosity does it change anything if you call init_platform manually with a larger count for thread pool

[rscarson]

Some debug logs showing the memory issue would also be useful

[kovaszab]

I'll have a look at my projects git history and prepare a simple example where this issue can be reproduced

[kovaszab]

Unfortunately I couldn't reproduce the issue either, even though checked out the exact revision of my repository where the issue arised consistently on my linux host. Cargo.lock showed no change in dependencies that could influence these results

[rscarson]

Unfortunately I couldn't reproduce the issue either, even though checked out the exact revision of my repository where the issue arised consistently on my linux host. Cargo.lock showed no change in dependencies that could influence these results

Going to close this for now then
Please reopen this issue if it happens again