Open Bug 1760123 Opened 4 years ago Updated 4 months ago

Intermittent netwerk/test/unit/test_udp_multicast.js | single tracking bug

Categories

(Core :: Networking, defect, P3)

All
Windows
defect

Tracking

()

People

(Reporter: jmaher, Unassigned, NeedInfo)

References

Details

(Keywords: intermittent-failure, intermittent-testcase, Whiteboard: [stockwell unknown][necko-triaged])

Attachments

(2 files, 1 obsolete file)

No description provided.
Severity: -- → S4
Whiteboard: [necko-triaged]

This seems to only fail on windows.
Maybe we can try to increase this timeout.

OS: All → Windows
Whiteboard: [necko-triaged][stockwell unknown][stockwell needswork:owner] → [necko-priority-review][stockwell unknown][stockwell needswork:owner]
  • Set the multicastLoopback = false flag before joining multicast group.
Assignee: nobody → valentin.gosu
Status: NEW → ASSIGNED
Attachment #9336736 - Attachment is obsolete: true
Comment 26 is private: false

(In reply to Valentin Gosu [:valentin] (he/him) from comment #26)

Doesn't actually fix the bug. The issue is that setting multicastLoopback and other methods calling nsUDPSocket::SetSocketOption are actually dispatched to the socket thread, so that's inherently racy,
I was able to easily reproduce the bug in TV mode on windows. I think the fix is to make the methods async.

Kershaw, as far as I can tell, all of our HTTP/3 calls are on the socket thread. If this isn't affecting quic, we can just fix the test by waiting for the socket thread task to be dispatched. Otherwise, if this is a race affecting quic, we should change the API and fix it properly.

Yes, all Http/3 calls are on the socket thread. I think we can just fix the test as you suggested.
Thanks.

Flags: needinfo?(kershaw)
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/487156a09e52 Intermittent netwerk/test/unit/test_udp_multicast.js r=necko-reviewers,jesup https://hg.mozilla.org/integration/autoland/rev/5ca4df9600a9 Fix test_udp_multicast.js lints r=necko-reviewers,jesup
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch

I just disabled it on win11 where most of the failures seemed to happen.
If failures stay at a high level we might want to disable this test on win10 as well.

Assignee: valentin.gosu → nobody
Status: REOPENED → NEW
Flags: needinfo?(valentin.gosu)
Status: NEW → RESOLVED
Closed: 3 years ago → 2 years ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → NEW
Whiteboard: [necko-priority-review][stockwell unknown][stockwell unknown] → [necko-priority-review][stockwell unknown][necko-triaged]
Flags: needinfo?(kershaw)
Whiteboard: [necko-priority-review][stockwell unknown][necko-triaged] → [stockwell unknown][necko-triaged]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #37)

I just disabled it on win11 where most of the failures seemed to happen.
If failures stay at a high level we might want to disable this test on win10 as well.

FYI these failures also affect more recent Windows 11 versions such as 23H2 (OS version 10.0.22631), which are not excluded through the mozinfo.win11_2009 condition (OS version 10.0.22621).

As a note, we only have certain versions in CI, there is an effort to upgrade by the end of the year to 24H2. It is confusing when what we test in CI is limited vs what is available in the marketplace.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: