Fix confusion of received response message#9
Merged
akr merged 1 commit intoruby:masterfrom May 11, 2021
Merged
Conversation
This is a follow up for commit 33fb966 ("Remove sender/message_id pair after response received in resolv", 2020-09-11). As the @senders instance variable is also used for tracking transaction ID allocation, simply removing an entry without releasing the ID would eventually deplete the ID space and cause Resolv::DNS.allocate_request_id to hang. It seems the intention of the code was to check that the received DNS message is actually the response for the question made within the method earlier. Let's have it actually do so. [Bug #12838] https://bugs.ruby-lang.org/issues/12838 [Bug #17748] https://bugs.ruby-lang.org/issues/17748
ccb0da2 to
53ca9c9
Compare
|
Good work! 👏 Should a regression test be added for this change? (e.g. |
mame
approved these changes
Apr 9, 2021
Member
mame
left a comment
There was a problem hiding this comment.
I'm not an expert in this area, but the change looks good to me.
stevenharman
approved these changes
May 1, 2021
eregon
added a commit
to eregon/truffleruby
that referenced
this pull request
May 4, 2021
* The version of resolv.rb in 2.7.3 seem to have several problems: https://bugs.ruby-lang.org/issues/17748 the fix is not released yet: ruby/resolv#9 probably related: https://bugs.ruby-lang.org/issues/17658 https://bugs.ruby-lang.org/issues/17781
eregon
added a commit
to eregon/truffleruby
that referenced
this pull request
May 4, 2021
* The version of resolv.rb in 2.7.3 seem to have several problems: https://bugs.ruby-lang.org/issues/17748 the fix is not released yet: ruby/resolv#9 probably related: https://bugs.ruby-lang.org/issues/17658 https://bugs.ruby-lang.org/issues/17781
|
I filed an issue yesterday since we recently ran into exactly this. See #11 (I missed this PR when I opened the issue.) I would +1 the suggestion for a unit test though, especially as the PR here effectively reverts the production code change from 33fb966 while leaving the test introduced in that commit in place. This indicates to me:
|
graalvmbot
pushed a commit
to truffleruby/truffleruby
that referenced
this pull request
May 7, 2021
* The version of resolv.rb in 2.7.3 seem to have several problems: https://bugs.ruby-lang.org/issues/17748 the fix is not released yet: ruby/resolv#9 probably related: https://bugs.ruby-lang.org/issues/17658 https://bugs.ruby-lang.org/issues/17781
Closed
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
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.
This is a follow up for commit 33fb966 ("Remove sender/message_id pair after response received in resolv", 2020-09-11).
As the senders instance variable is also used for tracking transaction ID allocation, simply removing an entry without releasing the ID would eventually deplete the ID space and cause Resolv::DNS.allocate_request_id to hang.
It seems the intention of the code was to check that the received DNS message is actually the response for the question made within the method earlier. Let's have it actually does so.
[Bug #12838] https://bugs.ruby-lang.org/issues/12838
[Bug #17748] https://bugs.ruby-lang.org/issues/17748