-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
await Promise.resolve("import('./mod.mjs')").then(eval)
rejects/segfaults in REPL
#43681
Comments
await Promise.resolve("import('./mod.js')").then(eval)
fails in REPLawait Promise.resolve("import('./mod.js')").then(eval)
rejects/segfaults in REPL
await Promise.resolve("import('./mod.js')").then(eval)
rejects/segfaults in REPLawait Promise.resolve("import('./mod.mjs')").then(eval)
rejects/segfaults in REPL
I can repro this on main, this is a neat find, thanks. @nodejs/loaders @nodejs/repl |
When running the scripts sequentially, the When running I'll try to dig into this. |
@legendecas I'm not sure whether it's related to this crash, but note that we are still using |
So, the reason I found this bug is that I was reading https://tc39.es/ecma262/#sec-hostmakejobcallback, which forces non-browser hosts to have a different behavior from browsers. HTML uses that host hook to implement support for So it's possible that the promise rejection (not the crash) is actually expected. |
This is actually expected in Node.js I argued at TC39 browsers should fail
too in 2019 or so. However, they didn't like that. Notes term should be
something about "incumbent realm". Node can allow it and ignore spec
non-web expectations. We had to do same with JSON impoer assertions due to
how web structured that semantics
…On Tue, Jul 5, 2022, 3:59 PM Nicolò Ribaudo ***@***.***> wrote:
When running console.log(6, await
Promise.resolve('import("./mod.mjs")').then(eval)); in a fresh REPL, the
referrer script unexpectedly becomes the internal/process/task_queues.js
instead of the REPL script. This can be problematic as the
host_defined_options is not the expected one for the REPL script.
So, the reason I found this bug is that I was reading
https://tc39.es/ecma262/#sec-hostmakejobcallback, which forces
non-browser hosts to have a different behavior from browsers. HTML uses
that host hook to implement support for Promise.resolve('import(
./example.mjs)').then(eval), so I wanted to test how Node.js behaves.
So it's possible that the promise rejection (not the crash) is actually
expected.
—
Reply to this email directly, view it on GitHub
<#43681 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABZJIZ3ZJXURUZJ7YW6Z2DVSSO2TANCNFSM52T5DMMQ>
.
You are receiving this because you are on a team that was mentioned.Message
ID: ***@***.***>
|
Version
v18.4.0
Platform
Linux nic-XPS-15-9570 5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:54:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
modules
What steps will reproduce the bug?
Have an empty
mod.mjs
file, and amain.mjs
file with the following contents:If you run
node main.mjs
, it works.However, if you open the REPL and copy-paste-run the first five lines one by one. Now kill the REPL, restart it, and run the sixth line: it throws
If you don't restart the REPL before running the sixth line, it almost always crashes with a segfault:
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
I assume that the last line should work in the REPL, because it works in a file and because all the other lines work in the REPL.
Even if the error is expected for some reason, it shouldn't segfault.
What do you see instead?
/
Additional information
No response
The text was updated successfully, but these errors were encountered: