Closed Bug 963244 Opened 10 years ago Closed 9 years ago

Intermittent B2G emulator test_dataChannel_basicAudio.html | Test timed out.

Categories

(Core :: WebRTC: Networking, defect)

Product:
Core
Component:
WebRTC: Networking
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1126036
Tracking Flags:
Tracking Status
firefox30 --- disabled
firefox31 --- disabled
b2g-v1.3 --- disabled
b2g-v1.3T --- disabled
b2g-v1.4 --- disabled
b2g-v2.0 --- disabled

People

(Reporter: jesup, Assigned: jesup)

Details

(Keywords: intermittent-failure, Whiteboard: [disabled on B2G emulator][leave open]) 

We've seen these on Debug emulator TBPL Trys, and I've seen them intermittently on opt local emulator runs.  We've never seen them on tbpl opt runs.

The timeout is due to the onopen for the datachannel not firing once audio and video connect; it *does* fire, but instead seems to be triggered by the timeout itself.  Adding more debugs and going deeper.
Something in the push below made this nearly perma-fail. Can't help but notice a patch from jib in there. Seems like either that or bug 688580 are the most likely candidates.

https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=b2g_emulator_vm%20mozilla-inbound%20opt%20test%20mochitest-7&rev=c63d8f19a893
Flags: needinfo?(jib)
Flags: needinfo?(bugs)
My patch here is merely a code-gen fix for upcoming use, and should not alter any existing code.
Flags: needinfo?(jib)
I ran Try runs of both bug 994465 and bug 688580 backed out, and neither improved things.
ryan: I'll note that b2g emulator (esp Debug) is *extremely* sensitive to CPU availability.  There's a patch to turn off "going to sleep" (forces the wakelock) that we should land that helps with some timeouts.  You could try adding that to a Try.  Bug 992436 (already r+'d)
Retriggers on inbound are actually pointing to the push prior, which includes bug 886110.

cset prior:  https://tbpl.mozilla.org/?tree=Try&rev=417437b07d7e
886110 cset: https://tbpl.mozilla.org/?tree=Try&rev=ec8cdd2bb135
Another guess is that it's the result of https://hg.mozilla.org/integration/mozilla-inbound/rev/c2350812b7f1 moving mochitests around and changing what's in which chunk
In particular, a diff of the start of the test list for chunk 7 looks like this:

-TEST-START | /tests/dom/indexedDB/test/test_setVersion_events.html
-TEST-START | /tests/dom/indexedDB/test/test_setVersion_exclusion.html
-TEST-START | /tests/dom/indexedDB/test/test_success_events_after_abort.html
-TEST-START | /tests/dom/indexedDB/test/test_third_party.html
-TEST-START | /tests/dom/indexedDB/test/test_traffic_jam.html
-TEST-START | /tests/dom/indexedDB/test/test_transaction_abort.html
-TEST-START | /tests/dom/indexedDB/test/test_transaction_abort_hang.html
-TEST-START | /tests/dom/indexedDB/test/test_transaction_lifetimes.html
 TEST-START | /tests/dom/indexedDB/test/test_transaction_lifetimes_nested.html
 TEST-START | /tests/dom/indexedDB/test/test_transaction_ordering.html
 TEST-START | /tests/dom/indexedDB/test/test_unique_index_update.html
 TEST-START | /tests/dom/indexedDB/test/test_webapp_clearBrowserData_inproc_inproc.html
 TEST-START | /tests/dom/indexedDB/test/test_webapp_clearBrowserData_inproc_oop.html
 TEST-START | /tests/dom/indexedDB/test/test_webapp_clearBrowserData_oop_inproc.html
 TEST-START | /tests/dom/ipc/tests/test_NuwaProcessCreation.html
 TEST-START | /tests/dom/media/tests/mochitest/test_dataChannel_basicAudio.html
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #52)
> Another guess is that it's the result of
> https://hg.mozilla.org/integration/mozilla-inbound/rev/c2350812b7f1 moving
> mochitests around and changing what's in which chunk

Probably.  And the wakelock landing didn't seem to help anything (much).  

As per m.d.platform, b2g debug is amazingly sensitive to even a little more realtime load.  We need to get the media tests off the current VM testbeds, or fix the VM.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #50)
> Retriggers on inbound are actually pointing to the push prior, which
> includes bug 886110.
> 
> cset prior:  https://tbpl.mozilla.org/?tree=Try&rev=417437b07d7e
> 886110 cset: https://tbpl.mozilla.org/?tree=Try&rev=ec8cdd2bb135

taking over from ryan here (since he also need to sleep) - the try runs from ryan didn't help and also were running into the timeouts. 

Now following the lead from dbaron about bug 946065 and backed this csets out to see if this helps to fix the test
Blocks: 946065
(Tweaking summary to make the difference between this bug and some of the other suggestions shown in TBPL at the same time, clearer)
Summary: Intermittent timeouts in test_datachannel_basicAudio.html on B2G emulator → Intermittent B2G emulator test_dataChannel_basicAudio.html | Test timed out.
(I know nothing about this test, and my patch didn't make this worse.)
Flags: needinfo?(bugs)
Disabled on B2G for being nearly perma-fail.
https://hg.mozilla.org/integration/b2g-inbound/rev/6c03acf73b19
status-firefox31: --- → disabled
Flags: needinfo?(ryanvm)
Whiteboard: [disabled on B2G emulator][leave open]
No longer blocks: 946065
byron - the last couple (comment 249 and comment 251, not 250) here are not this bug officially (which is b2g only, and disabled there), but may be related or may be a separate/new bug.  It appears it hung waiting for remote ICE to be connected (it may have been connected but perhaps the test didn't capture it).

09:34:49 INFO - 100 INFO Run step: PC_REMOTE_WAIT_FOR_ICE_CONNECTED
09:34:49 INFO - 101 INFO PeerConnectionWrapper (pcRemote): iceConnectionState = checking 

Thoughts? (mt?)
Flags: needinfo?(docfaraday)
This looks like bug 1126036 to me. Comment 248 happened after the first landing of bug 949703, but before the backout, the rest happened between the final landing of bug 949703 but before bug 1126036, and the logs look like the failure logs I was seeing.
Flags: needinfo?(docfaraday)
I'd concur with Byron here.  This is exactly the problem that I was seeing.  bug 1119593 made this a permanent fail, but bug 1126036 fixed it.  If this doesn't appear again in the next few days, we're golden.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.