Repository navigation
Conversation
With a 100ms cooldown the alarms repeat every 100ms or a bit more, while do_recv_connection_alarms stopped after 100ms without messages. An alarm firing just after the window closed made the test fail. Collect alarms until a fixed deadline instead and use a window larger than the cooldown.
Member
|
@grok-99s When you say you couldn't reproduce the failure locally, do you mean before your fix? |
Collaborator
Author
|
Yes, before the fix. Those 20 runs under CPU load were on unpatched master and none of them failed. The 10/10 passes were with the fix applied. So the change follows from reading the timing in the code, not from a local reproduction. |
Member
|
Deferred until a way to reproduce is figured out. |
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
2 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.
acceptor_SUITE:misc_connection_alarmsfailed with{badmatch,#{test1 => undefined,test2 => undefined}}at line 650 on OTP-28.5.0.7 macos-14 in scheduled run 37262937056.After
cooldown => 100is set, the alarms fire again every 100ms or a little more, since that counts timer latency plus the callback being spawned.do_recv_connection_alarms/2stopped after 100ms passed with no message. When the previous alarm had just been flushed, the next one could arrive slightly after that 100ms window closed, so nothing was received. The idle-reset timeout also meant a window longer than the cooldown would never end while alarms keep repeating.This change makes
do_recv_connection_alarms/2collect messages until a fixed deadline. The four checks that run with the 100ms cooldown now use a 200ms window. That window always contains at least one repeat, and the checks expectingundefinedstill hold because those alarms are below their threshold.I couldn't reproduce the failure locally in 20 runs under CPU load. After the change, the test passed 10 out of 10 runs and the
miscgroup passes (OTP 27.3.4.1).