Closed Bug 1550691 Opened 1 year ago Closed 1 year ago

High frequency intermittent Tier 2 TEST-UNEXPECTED-TIMEOUT | /webrtc/RTCDataChannel-bufferedAmount.html | Data channel bufferedamountlow event fires after send() is complete - Test timed out

Categories

(Core :: WebRTC, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- wontfix
firefox70 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: bwc)

Details

(Keywords: intermittent-failure, regression)

Attachments

(2 files)

Filed by: rgurzau [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=245697384&repo=mozilla-central
Full log: https://queue.taskcluster.net/v1/task/VQjP1VjfQhSmt_PjrVoujA/runs/0/artifacts/public/logs/live_backing.log


06:23:55 INFO - TEST-PASS | /webrtc/RTCDataChannel-bufferedAmount.html | bufferedAmount should increase by byte length for each message sent
06:23:55 INFO - TEST-PASS | /webrtc/RTCDataChannel-bufferedAmount.html | bufferedAmount should not decrease immediately after initiating closure
06:23:55 INFO - TEST-PASS | /webrtc/RTCDataChannel-bufferedAmount.html | bufferedAmount should not decrease after closing the peer connection
06:23:55 INFO - TEST-UNEXPECTED-TIMEOUT | /webrtc/RTCDataChannel-bufferedAmount.html | Data channel bufferedamountlow event fires after send() is complete - Test timed out
06:23:55 INFO -
06:23:55 INFO - TEST-UNEXPECTED-NOTRUN | /webrtc/RTCDataChannel-bufferedAmount.html | Data channel bufferedamount is data.length on send(data) - expected PASS
06:23:55 INFO -
06:23:55 INFO - TEST-UNEXPECTED-NOTRUN | /webrtc/RTCDataChannel-bufferedAmount.html | Data channel bufferedamount returns the same amount if no more data is sent on the channel - expected PASS
06:23:55 INFO -
06:23:55 INFO - TEST-UNEXPECTED-NOTRUN | /webrtc/RTCDataChannel-bufferedAmount.html | Data channel bufferedamountlow event fires only once after multiple consecutive send() calls - expected PASS
06:23:55 INFO -
06:23:55 INFO - TEST-UNEXPECTED-NOTRUN | /webrtc/RTCDataChannel-bufferedAmount.html | Data channel bufferedamountlow event fires after each sent message - expected PASS
06:23:55 INFO - TEST-UNEXPECTED-TIMEOUT | /webrtc/RTCDataChannel-bufferedAmount.html | expected OK
06:23:55 INFO - TEST-INFO took 41241ms

Maybe we should mark this test as long; it requires ICE to complete in a number of test cases.

Assignee: nobody → docfaraday
Priority: P5 → P2

Bug 1558851 just landed, which marked this test as expected to fail on aarch64. I need to rebase once that change makes it to central, and see if we can re-enable those test-cases.

Flags: needinfo?(docfaraday)

Depends on D34356

Seeing an assertion on test-verify on Win 7:

17:34:40 INFO - Crash reason: EXCEPTION_BREAKPOINT
17:34:40 INFO - Crash address: 0x559046ce
17:34:40 INFO - Assertion: Unknown assertion type 0x00000000
17:34:40 INFO - Process uptime: 5 seconds
17:34:40 INFO -
17:34:40 INFO - Thread 12 (crashed)
17:34:40 INFO - 0 xul.dll!mozilla::DataChannelConnection::DestroyOnSTSFinal() [DataChannel.cpp:89229601e0dee4e9563041b6d548e0bdadb0db2b : 378 + 0x29]
17:34:40 INFO - eip = 0x559046ce esp = 0x0600ea84 ebp = 0x0600ea84 ebx = 0x00000000
17:34:40 INFO - esi = 0x0600ea8c edi = 0x55904690 eax = 0x6c8926dc ecx = 0x00000095
17:34:40 INFO - edx = 0x00000049 efl = 0x00000206
17:34:40 INFO - Found by: given as instruction pointer in context
17:34:40 INFO - 1 xul.dll!nsresult mozilla::runnable_args_memfn<RefPtr<mozilla::DataChannelConnection>,void (mozilla::DataChannelConnection::*)() attribute((thiscall))>::Run() [runnable_utils.h:89229601e0dee4e9563041b6d548e0bdadb0db2b : 148 + 0x9]
17:34:40 INFO - eip = 0x5590fd71 esp = 0x0600ea8c ebp = 0x0600eab4
17:34:40 INFO - Found by: call frame info

Looks like a low-frequency, pre-existing bug to me. Retriggering to see...

Also, that try push didn't run aarch64 for some reason.

Try looks good so far, but retriggering to verify.

Flags: needinfo?(docfaraday)

Wow, those retriggers have been pending for a long time.

Awesome, the retriggers never ran. Retriggering again...

Ok, it looks like we're still getting timeouts in this test on other test-cases, so marking this as "long" is something we definitely need to do. On top of that, the ini file means that we always expect a timeout, which hints that the timeout is pretty consistent, so a clean try push without retriggers is good enough for me.

Flags: needinfo?(docfaraday)
Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/88f4378ccf1a
Mark this test as long, because it requires ICE to complete. r=jib
https://hg.mozilla.org/integration/autoland/rev/813fc70ec1f2
Re-enable this test on aarch64. r=jib
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/17764 for changes under testing/web-platform/tests

No failures since this landed, but low frequency. I'll check back next week.

Flags: needinfo?(docfaraday)

Yeah, this looks fixed.

Flags: needinfo?(docfaraday)
You need to log in before you can comment on or make changes to this bug.