Open Bug 1255293 Opened 8 years ago Updated 11 months ago

Intermittent TEST-UNEXPECTED-FAIL | TestNrSocketTest.PrivateToPublicConnectivityTcp | Value of: CheckTcpConnectivity(private_addrs_[0], public_addrs_[0])

Categories

(Core :: WebRTC: Networking, defect, P4)

defect

Tracking

()

Tracking Status
firefox48 --- affected

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure)

Blocks: 1255714
Rank: 35
Component: Audio/Video → WebRTC: Networking
Priority: -- → P3
Byron, I'm wondering is the 10.6 machine is just so slow that the 500ms timeout for waiting for readable is too little, or is their a race condition here:
https://dxr.mozilla.org/mozilla-central/source/media/mtransport/test/test_nr_socket_unittest.cpp#388

Should we get a readable callback any time after the connect succeeded?
Or would we need to setup the readable callback before doing to connect, because the readable callback will only fire right after connecting?
I would assume and hope the former, but I'm not sure.
Flags: needinfo?(docfaraday)
Even if the socket becomes readable before doing the NR_ASYNC_WAIT, this should still work, because these waits aren't edge triggered. My suspicion is there's something wrong in the NAT simulator TCP code.
Flags: needinfo?(docfaraday)
Assignee: nobody → docfaraday
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4

Check whether the logging added in bug 1283943 helps shed any light on this.

Flags: needinfo?(docfaraday)

Hasn't happened in a couple of weeks. If it happens again, I can look into it.

Flags: needinfo?(docfaraday)
Severity: normal → S3
Assignee: docfaraday → nobody
You need to log in before you can comment on or make changes to this bug.