New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 4225 link

Starred by 6 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

rtc_unittests P2PTransportChannelTest tests fail when run in parallel

Project Member Reported by kjellander@webrtc.org, Jan 26 2015

Issue description

What steps will reproduce the problem?
1. Build rtc_unittests in Release mode on Windows (I have only seen it happening on this platform)
2.
3.Run: python third_party\gtest-parallel\gtest-parallel out\Release \rtc_unittests -w 20 -r 100 --gtest_filter=P2PTransportChannelTest.*

What is the expected result?
All tests should pass.

What do you see instead?
Some tests fail, like:

[ RUN      ] P2PTransportChannelTest.TestNAT_SYMMETRICToNAT_SYMMETRIC_THEN_CONEAsIce
[000:000] Jingle:Net[test0:192.168.1.0/24:Unknown]: Allocation Phase=Udp
[000:172] Jingle:Port[:1:0::Net[test0:192.168.1.0/24:Unknown]]: Port created

...jingle messages omitted...

e:\b\build\slave\win\build\src\webrtc\p2p\base\p2ptransportchannel_unittest.cc(459): error: Value of: LocalCandidate(ep2_ch1())->type()
  Actual: "prflx"
Expected: expected.local_type2
Which is: "relay"
e:\b\build\slave\win\build\src\webrtc\p2p\base\p2ptransportchannel_unittest.cc(474): error: Value of: expected.remote_type2 == cricket::LOCAL_PORT_TYPE || expected.remote_type2 == cricket::STUN_PORT_TYPE
  Actual: false
Expected: true
e:\b\build\slave\win\build\src\webrtc\p2p\base\p2ptransportchannel_unittest.cc(478): error: Value of: RemoteCandidate(ep2_ch1())->type() == cricket::LOCAL_PORT_TYPE || RemoteCandidate(ep2_ch1())->type() == cricket::STUN_PORT_TYPE || RemoteCandidate(ep2_ch1())->type() == cricket::PRFLX_PORT_TYPE
  Actual: false
Expected: true
[006:615] Converge time: TIMEOUT (2000 ms)


[ RUN      ] P2PTransportChannelTest.TestNAT_ADDR_RESTRICTEDToNAT_SYMMETRIC_THEN_CONEAsGiceP0SharedUfrag
[000:000] Jingle:Net[test0:192.168.1.0/24:Unknown]: Allocation Phase=Udp

...jingle messages omitted...

[000:577] Connect time: 577 ms
[000:624] Packet from 11.11.11.11:49155 was filtered out by the NAT.
[002:137] Packet from 11.11.11.11:49155 was filtered out by the NAT.
[002:589] Warning(p2ptransportchannel_unittest.cc:438): Expression LocalCandidate(ep1_ch1())->type() == expected.local_type && LocalCandidate(ep1_ch1())->protocol() == expected.local_proto && RemoteCandidate(ep1_ch1())->type() == expected.remote_type && RemoteCandidate(ep1_ch1())->protocol() == expected.remote_proto still not true after 2000ms; waiting an additional 2000ms
[003:104] Packet from 11.11.11.11:49155 was filtered out by the NAT.
e:\b\build\slave\win\build\src\webrtc\p2p\base\p2ptransportchannel_unittest.cc(438): error: Value of: LocalCandidate(ep1_ch1())->type() == expected.local_type && LocalCandidate(ep1_ch1())->protocol() == expected.local_proto && RemoteCandidate(ep1_ch1())->type() == expected.remote_type && RemoteCandidate(ep1_ch1())->protocol() == expected.remote_proto
  Actual: false
Expected: true
e:\b\build\slave\win\build\src\webrtc\p2p\base\p2ptransportchannel_unittest.cc(443): error: Value of: RemoteCandidate(ep1_ch1())->type()
  Actual: "local"
Expected: expected.remote_type
Which is: "stun"
[004:695] Converge time: TIMEOUT (2000 ms)
[  FAILED  ] P2PTransportChannelTest.TestNAT_ADDR_RESTRICTEDToNAT_SYMMETRIC_THEN_CONEAsGiceP0SharedUfrag (5039 ms)

See 
http://build.chromium.org/p/client.webrtc/builders/Win32%20Debug/builds/3523/steps/rtc_unittests/logs/stdio
http://build.chromium.org/p/client.webrtc/builders/Win64%20Debug/builds/3204/steps/rtc_unittests/logs/stdio
for full logs.

This was discovered when enabling parallel test execution. It is currently only enabled for builders in http://build.chromium.org/p/client.webrtc.fyi/waterfall


Please use labels and text to provide additional information.

 
Project Member

Comment 1 by kjellander@webrtc.org, Jan 26 2015

I think it might actually only happen when building Debug mode, so please replace Release with Debug above.
Project Member

Comment 2 by pbos@webrtc.org, Jan 26 2015

I bet it's a timing thing, so debug vs release is probably just because one is a bit faster than the other. (I think map iterators for instance are a lot slower in debug.)
Project Member

Comment 3 by pthatcher@google.com, Jan 26 2015

Owner: guoweis@webrtc.org
pbos, how close to getting to parallel tests are we?  Is this the last one?  If so, then we'd bump the priority.  Otherwise, we'll treat this as lower priority.
Project Member

Comment 4 by pthatcher@google.com, Jan 26 2015

Labels: EngTriaged Mstone-44
Project Member

Comment 5 by pbos@webrtc.org, Jan 26 2015

Cc: kjellander@webrtc.org
We're running parallel test on Linux atm. We tried flipping the switch on Windows after it'd been green in the FYI waterfall for a while but ran into this.

kjellander@ how many flakes do you estimate is left? Is it just this and the other one that's assigned to me?
Project Member

Comment 6 by kjellander@webrtc.org, Jan 27 2015

Re #3: Yes, this and  issue 4226  should be the only ones remaining before we can enable this on Windows, which will be a huge improvement on the buildbots.

I filed  issue 4233  today though, but I'm not sure what causes those failures.
Project Member

Comment 7 by kjellander@webrtc.org, Dec 7 2015

Labels: fixit size-tiny
Candidate to move into the new webrtc_nonparallel_tests target and re-enable?
Project Member

Comment 8 by pbos@webrtc.org, Dec 7 2015

Only if this test is using physical ports imo.
Project Member

Comment 9 by juberti@webrtc.org, Feb 1 2016

Labels: Hotlist-Testing
Project Member

Comment 10 by pthatcher@webrtc.org, Feb 8 2016

Owner: deadbeef@webrtc.org
I might have fix this back when I was working on triggered checks.  We may want to remove the "flaky" descriptors and see if the bots will be green.
Project Member

Comment 11 by pthatcher@webrtc.org, Feb 8 2016

Labels: -Mstone-44
Project Member

Comment 12 by kjellander@webrtc.org, May 26 2016

This hit again at https://build.chromium.org/p/client.webrtc/builders/Linux%20UBSan%20vptr/builds/1355/steps/rtc_unittests/logs/stdio
today. Is this another one that should be moved to webrtc_nonparallel_tests?

Log snippet:
[001:317] (port.cc:593): Jingle:Port[0x37a1810:test content name:1:0::Net[test0:192.168.1.x/24:Unknown]]: Sent STUN ping response, to=22.22.22.x:49159, id=6952366e6b432f5256626535
../../webrtc/p2p/base/p2ptransportchannel_unittest.cc:553: Failure
Value of: CheckCandidate2(expected)
  Actual: false
Expected: true
../../webrtc/p2p/base/p2ptransportchannel_unittest.cc:502: Failure
Value of: remote_type
  Actual: "relay"
Expected: expected.remote_proto2
Which is: "udp"
../../webrtc/p2p/base/p2ptransportchannel_unittest.cc:503: Failure
Value of: local_type
  Actual: "prflx"
Expected: expected.local_type2
Which is: "relay"
../../webrtc/p2p/base/p2ptransportchannel_unittest.cc:509: Failure
Value of: remote_type == cricket::LOCAL_PORT_TYPE || remote_type == cricket::STUN_PORT_TYPE || remote_type == cricket::PRFLX_PORT_TYPE
  Actual: false
Expected: true
[001:835] (p2ptransportchannel_unittest.cc:559): Converge time: 1047 ms
[001:857] (turnport.cc:1241): Jingle:Port[0x37a1810:test content name:1:0::Net[test0:192.168.1.x/24:Unknown]]: TURN refresh request sent, id=4d76454b6d6744696477486f
[001:857] (turnport.cc:1241): Jingle:Port[0x37b2bb0:test content name:1:0::Net[test0:192.168.2.x/24:Unknown]]: TURN refresh request sent, id=4f4854594a396b6757786b58
[001:858] (turnserver.cc:585): Jingle:Alloc[11.11.11.11:49152-:0:unknown]: Allocation destroyed
[001:858] (turnserver.cc:585): Jingle:Alloc[22.22.22.22:49154-:0:unknown]: Allocation destroyed
[  FAILED  ] P2PTransportChannelTest.TestNAT_PORT_RESTRICTEDToNAT_SYMMETRIC (1858 ms)

Project Member

Comment 13 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Project Member

Comment 14 by deadbeef@chromium.org, Apr 3

Owner: ----
Status: Available (was: Assigned)
Clearing owner and setting status to Available, since there haven't been any updates for > 1 year. Will be assigned again once priority is high enough.

Sign in to add a comment