node icon indicating copy to clipboard operation
node copied to clipboard

Node.js REPL freezes with "while (true);" or "while (true){}" input

Open dmand-commits opened this issue 1 year ago • 14 comments

Version

v22.5.1

Platform

Linux linux 6.10.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 27 Jul 2024 16:49:55 +0000 x86_64 GNU/Linux

Subsystem

no modules were involved

What steps will reproduce the bug?

Open Node.js interactive mode by typing node in the terminal. 2. Enter while (false){} or while (false);.

  • Notice the "undefined" display ready to be output.
  1. Enter while (true); or while (true){}.
    • The terminal freezes and becomes unresponsive.

How often does it reproduce? Is there a required condition?

It reproduces 100% of the time, the required condition is that you're on node.js interactive shell.

What is the expected behavior? Why is that the expected behavior?

the expected behavior would be the return value of the block of code used in the while-loop, since 'while (false);' returned undefined, something predictably consistent is also expected with 'while (true);'

What do you see instead?

The terminal stops working until I kill the process manually with htop or kill command from another terminal.

Additional information

the issue is that in node.js interactive mode, when I type "while (false){}" or "while (false);" it will make a vague display of undefined ready to be output, sort of like a google suggestion. Now, here's the real deal issue: try typing "while (true);" or "while (true){}" instead. Your terminal will freeze and the only way to stop node.js at that point would be to kill the process with kill or htop. I think I know the reason behind the issue: the "semi-google-suggestion-like" vague display. Its purpose is it show you what is ready to be displayed when you press Enter, to save you ease and time by assuming that you likely are just wanting to glance at outcomes oftentimes. But to achieve this process of simulating the google-like output display, it has to execute the command in the background, and wait for the return result of executing that command, then send it to the vague display, therefore resulting in the bug that freezes your terminal when you type "while (true);" in interactive mode.

dmand-commits avatar Aug 03 '24 17:08 dmand-commits

This seems to be working as intended.

While loops block the main thread, meaning no other execution can occur, hence the hanging.

I've optimisticly marked this as wontfix, but another member of the org can always change that. If members agree, please close the issue as "Not planned".

avivkeller avatar Aug 04 '24 14:08 avivkeller

I believe the issue is that the repl hangs when you type in while(true); without pressing enter (meaning the preview evaluation causes the hanging). It doesn't happen when running with TERM=dumb (which disables the preview) and also doesn't seem to happen on node 20.

The preview evaluation works by sending a Runtime.evaluate command to the v8 inspector with a timeout of 333ms, but it looks like the timeout is ignored in this case.

jfhr avatar Aug 04 '24 15:08 jfhr

Oh okay. I've adjusted the labels, thanks!

avivkeller avatar Aug 04 '24 15:08 avivkeller

Yeah, exactly, the issue is with the preview, which simulates code execution and relies on it completing to show you the preview; if the code never finishes execution theoretically the response keeps waiting indefinitely and the tty is rendered unresponsive.

On Sun, Aug 4, 2024 at 6:30 PM Aviv Keller @.***> wrote:

Oh okay. I've adjusted the labels, thanks!

— Reply to this email directly, view it on GitHub https://github.com/nodejs/node/issues/54193#issuecomment-2267581307, or unsubscribe https://github.com/notifications/unsubscribe-auth/BJ6CR56VXKRXVU6JYGUQ7HDZPZCI7AVCNFSM6AAAAABL6CU246VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGU4DCMZQG4 . You are receiving this because you authored the thread.Message ID: @.***>

dmand-commits avatar Aug 05 '24 11:08 dmand-commits

The preview should be limited to 333ms. That's the hardcoded limit that is defined in the code. Could someone check if this is an issue with Node.js vs V8?

BridgeAR avatar Aug 05 '24 11:08 BridgeAR

Looking in to it @BridgeAR

MrJithil avatar Aug 09 '24 13:08 MrJithil

Its an issue from v8. Reporting to v8 and will analyze there.

MrJithil avatar Aug 12 '24 08:08 MrJithil

Please close the ticket as known deps issue.

MrJithil avatar Aug 12 '24 08:08 MrJithil

@MrJithil could you provide more information about why this is a known issue, what exactly goes wrong on V8?

Thanks!

avivkeller avatar Aug 12 '24 22:08 avivkeller

I see. Runtime.evaluate is ignoring the timeout.

avivkeller avatar Sep 14 '24 22:09 avivkeller

@nodejs/v8 the runtime inspector is not respecting the timeout parameter

avivkeller avatar Sep 19 '24 22:09 avivkeller

Yes. This has to be fixed in v8. Thats why it's a known dep issue.

MrJithil avatar Oct 06 '24 10:10 MrJithil

https://issues.chromium.org/issues/371768644

MrJithil avatar Oct 06 '24 10:10 MrJithil

This was introduced in https://github.com/nodejs/node/pull/49639. V8 option --no-use-osr can be a workaround to fix the issue.

Running with --trace-osr, the log shows that there is an infinite loop around osr compilation:

[OSR - compilation started. function: , osr offset: 2, mode: ConcurrencyMode::kConcurrent]
[OSR - unavailable (failed or in progress). function: , osr offset: 2, mode: ConcurrencyMode::kConcurrent]
[OSR - compilation started. function: , osr offset: 2, mode: ConcurrencyMode::kConcurrent]
[OSR - unavailable (failed or in progress). function: , osr offset: 2, mode: ConcurrencyMode::kConcurrent]
[OSR - compilation started. function: , osr offset: 2, mode: ConcurrencyMode::kConcurrent]

V8 Issue: https://issues.chromium.org/issues/374013413

legendecas avatar Oct 17 '24 10:10 legendecas