erts: Fix missing poll error - #11298
Open
garazdawi wants to merge 6 commits into
Open
Conversation
Consider this scenario: 1. Read FD signals EOF 2. ready_input called and read returns 0 3. call port_inp_failure, wait for SigChld 4. spawn_control called with SigChld, triggering driver_select on read fd 5. ready_input called again and now exit_status is delivered Not all OSs actually trigger a second poll signal when we re-select on an FD has already signaled EOF. So if that trigger never happens then step 5 is left out and no exit_status is delivered. closes erlang#11278
port_inp_failure also does the deselect
Contributor
CT Test Results 3 files 136 suites 50m 50s ⏱️ Results for commit 2b4d636. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
garazdawi
force-pushed
the
lukas/erts/missing-poll-error
branch
from
June 26, 2026 10:33
811cd90 to
bd628c7
Compare
When an FD was in a scheduler pollset and poll-thread it was possible that an error event was lost on the read end if both read and write polling was enabled (though not necessarily actived). The scenario was like this: 1. Write FD in poll-thread, used but not activated. Read FD in scheduler, used and activated. 2. Data arrives on read fd followed by EOF. 3. ready_input is scheduled for the data on read FD. 4. The EOF triggers the write FD to return ERROR which triggers a ready_input event and deletes the FD from the scheduler pollset and the poll-thread pollset. 5. The ready_input is ignored as there is already one in flight. 6. The running ready_input returns and does not re-arm the FD as it assumes it is already in the scheduler pollset. 7. The FD is in an EOF state, but the FD has been removed from both pollsets so no trigger ever comes which makes the port leak and never send its eof/exit_status. This is fixed by an ERROR in the poll-thread when the fd is migrated to the scheduler pollset to not delete the FD, but instead let it be deleted when the scheduler pollset later calls check_io and detects that the fd is in an error state. We can remove the redundant select in spawn_control as it was just compensating for the fact that this bug existed. This bug was introduced in erlang#9275.
garazdawi
force-pushed
the
lukas/erts/missing-poll-error
branch
from
June 26, 2026 12:36
bd628c7 to
2b4d636
Compare
lucioleKi
added
the
testing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When investigating #11278 I noticed that #11285 did not fix the issue completely on Erlang/OTP 28 and later. After a bit of digging i found that there was a race in the scheduler pollset handling when the FD returned an error.
The scenario was like this:
Read FD in scheduler, used and activated.
This PR builds on top for #11285, but is aimed at Erlang/OTP 28 and later. It also contains some minor refactors that I found useful when debugging this.
I've not included any testcase as this is very racy and triggering it required me to run a test for a very long time.
The bug was introduced in #9275 which was part of Erlang/OTP 28.0.