worker core dumped panic

[MierenManz]

const b64 = btoa(
  'await new Promise((res) => setTimeout(res, 1000));throw "error";',
);

const w = new Worker(`data:application/javascript;base64,${b64}`, {
  type: "module",
});

w.onerror = (e) => console.log("some error occured");
w.terminate();

This code has a chance to "panic" with a core dumped error on linux.
Both on deno 1.15.3 and canary(1.15.3+26a5471)

C stacktrace

#
# Fatal error in , line 0
# Check failed: (location_) != nullptr.
#
#
#
#FailureMessage Object: 0x7f620b7da3b0
==== C stack trace ===============================

    deno(+0x1b44ef3) [0x55aa66f9eef3]
    deno(+0x1b3ff6b) [0x55aa66f99f6b]
    deno(+0x1b40bb5) [0x55aa66f9abb5]
    deno(+0x1fc7385) [0x55aa67421385]
    deno(+0x1fc6be1) [0x55aa67420be1]
    deno(+0x1fc666d) [0x55aa6742066d]
    deno(+0x1fc64bc) [0x55aa674204bc]
    deno(+0x1b966ac) [0x55aa66ff06ac]
    deno(+0x35cfdb2) [0x55aa68a29db2]
    deno(+0x3090858) [0x55aa684ea858]
    deno(+0x2f3489c) [0x55aa6838e89c]
    deno(+0x2f3e4c2) [0x55aa683984c2]
    deno(+0x2954703) [0x55aa67dae703]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x9450) [0x7f6213336450]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f621310ad53]
Trace/breakpoint trap (core dumped)

[andreubotella]

Although it's very rare, this code can also yield a Rust panic:

thread 'worker-0' panicked at 'assertion failed: status == v8::ModuleStatus::Errored', core/runtime.rs:1127:7
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

See #12713.

[andreubotella]

Filed as a V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=12379

[andreubotella]

I've been looking into why the V8 bug doesn't crash Chrome, and it seems like what they do is, rather than terminating the worker's instance immediately, they:

1. Signal to the worker thread that any long-running synchronous APIs must terminate. (I'm not sure exactly how this happens, or whether it can be replicated in Deno. Is this a thing we should care about?)
2. Send a message to the worker's thread asking it to terminate.
3. After a 2-second timeout, post a task on the current thread that will terminate the worker's isolate if it hasn't already.

Since v8::Module::evaluate is a synchronous function, the only case where this bug would be triggered in Chrome's model is if a worker's main module has TLA and has an endless loop before the first await point. A few cursory tests confirm that Chrome does indeed crash in this case.

Should we consider following the same model?