-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
stdin redirection hangs on macOS #10080
Labels
bug
Something isn't working
Comments
alexkornitzer
added a commit
to alexkornitzer/bun
that referenced
this issue
Apr 16, 2024
…h#10080) The FileReader is responsible for deciding what sort of file descriptor has been passed to it. On MacOS, when stdin is provided to it the FileReader assumes that it is nonblocking even if the descriptor is not, this resulted in hangs as the socket would never raise the `EAGAIN` error. There are a couple of ways to fix this but the one that seemed to make the most sense was to set the fd to be nonblocking when the FileReader deemed it so.
alexkornitzer
added a commit
to alexkornitzer/bun
that referenced
this issue
Apr 16, 2024
The FileReader is responsible for deciding what sort of file descriptor has been passed to it. On MacOS, when stdin is provided to it the FileReader assumes that it is nonblocking even if the descriptor is not as it passes the pollable and not a tty check, this then results in hangs as the reader expects `EAGAIN`. To fix this we now check the file descriptor to see if it is nonblocking rather than using assumptions.
alexkornitzer
added a commit
to alexkornitzer/bun
that referenced
this issue
Apr 16, 2024
The FileReader is responsible for deciding what sort of file descriptor has been passed to it. On MacOS, when stdin is provided to it the FileReader assumes that it is nonblocking even if the descriptor is not as it passes the pollable and not a tty check, this then results in hangs as the reader expects `EAGAIN`. To fix this we now check the file descriptor to see if it is nonblocking rather than using assumptions.
alexkornitzer
added a commit
to alexkornitzer/bun
that referenced
this issue
May 2, 2024
The FileReader is responsible for deciding what sort of file descriptor has been passed to it. On MacOS, when stdin is provided to it the FileReader assumes that it is nonblocking even if the descriptor is not as it passes the pollable and not a tty check, this then results in hangs as the reader expects `EAGAIN`. To fix this we now check the file descriptor to see if it is nonblocking rather than using assumptions.
alexkornitzer
added a commit
to alexkornitzer/bun
that referenced
this issue
May 31, 2024
The FileReader is responsible for deciding what sort of file descriptor has been passed to it. On MacOS, when stdin is provided to it the FileReader assumes that it is nonblocking even if the descriptor is not as it passes the pollable and not a tty check, this then results in hangs as the reader expects `EAGAIN`. To fix this we now check the file descriptor to see if it is nonblocking rather than using assumptions.
I can also reproduce this behavior using Bun as the runtime for my chess engine, postbot. Since Bun v1.0.31, the engine has stopped working with BanksiaGUI or the lichess-bot wrapper. According to the logs, it appears that stdin stops working after the first input. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since Bun v1.0.31 which had the major IO rework, talking to Bun via an Erlang Port (https://www.erlang.org/doc/tutorial/c_port) has resulted in hangs on macOS. After investigation the issue appears to come from assumptions that Bun makes in its
FileReader
(https://github.com/oven-sh/bun/blob/main/src/bun.js/webcore/streams.zig#L3441), resulting in it setting the reader as non blocking when the file descriptor is not. This then results in a hang as thePosixBufferedReader
handles reads in a non blocking way while the read syscall is blocking, thusEAGAIN
is never raised.I have used a rather forceful approach in local testing to fix the issue which just ensures the file descriptor is non blocking (using the already present but what appears to be unused function).
I have not raised a PR for this as I understand the fix might be to handle the broken assumptions for macOS builds rather than forcing the descriptor to be non blocking.
The following was used to reproduce the error:
test.js
wrapper.sh
The text was updated successfully, but these errors were encountered: