Closed Bug 964685 Opened 10 years ago Closed 10 years ago

Intermittent test_dataChannel_basicDataOnly.html | Test timed out. ("ABORT: corrupted actor state: file PTelephony.cpp, line 35")

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla32
Tracking Flags:
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
firefox-esr24 --- unaffected
b2g-v1.4 --- disabled
b2g-v2.0 --- fixed

People

(Reporter: cbook, Assigned: drno)

References

(
URL
)

Details

(Keywords: intermittent-failure) 

b2g_emulator_vm b2g-inbound debug test mochitest-debug-6 on 2014-01-27 23:34:31 PST for push 571dea2d6083

slave: tst-linux64-spot-065

https://tbpl.mozilla.org/php/getParsedLog.php?id=33677571&tree=B2g-Inbound

TEST-UNEXPECTED-FAIL | /tests/dom/media/tests/mochitest/test_dataChannel_basicDataOnly.html | Test timed out.
Summary: TEST-UNEXPECTED-FAIL | tests/mochitest/test_dataChannel_basicDataOnly.html | Test timed out. → Intermittent test_dataChannel_basicDataOnly.html | Test timed out. ("ABORT: corrupted actor state: file PTelephony.cpp, line 35")
This is basically perma-fail on b2g30 (v1.4) at the moment. My suspicion based on when it started is that disabling test_video_wakelock.html in bug 881443 changed the test chunking around just enough to make this test angry.

Nils, any chance you could take a look at what's going on here? :)
Flags: needinfo?(drno)
Looks like it's always at about the same point during "Run step: PC_REMOTE_SET_LOCAL_DESCRIPTION"
I've pushed a backout of bug 881443 to test the theory in comment 186.
Yup, "fixed". *sigh*
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #187)
> Looks like it's always at about the same point during "Run step:
> PC_REMOTE_SET_LOCAL_DESCRIPTION"

So the problem is that currently in the step "PC_REMOTE_SET_LOCAL_DESCRIPTION" the dataChannel tests are sitting waiting for the data channel to get established. And they do this by depending on events getting fired. My theory is that this does not work reliable.

But I don't understand enough of this yet to get why or how wakelock influences this. Randel do you understand how wakelock affects this dataChannel test?

I think we have two options here:
1) Wait for until I clean up the data channel tests in bug 1013809 (that could take several days).
2) Disable the data channel tests on B2G for now and look into re-enabling them once bug 1013809 is landed and has proven to improve things.
Flags: needinfo?(drno) → needinfo?(rjesup)
I have no idea why wakelock would affect things - other than going to sleep may slow down tests enough to time out.  We/I added code to force wakelock on for mochitests in general on b2g emulator to reduce timeouts; perhaps the wakelock test broke that - caused it to no longer be forced on after it runs?
Flags: needinfo?(rjesup)
Looks like this went away on everything except b2g30 after bug 1013809 landed. Unfortunately, that doesn't look trivial to backport to b2g30 (part 3 in particular) :(
Disabled on b2g30. Otherwise, calling this fixed by bug 1013809.
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/0616da9bdf09
Assignee: nobody → drno
Status: NEW → RESOLVED
Closed: 10 years ago
status-b2g-v1.4: --- → disabled
status-b2g-v2.0: --- → fixed
status-firefox30: --- → wontfix
status-firefox31: --- → wontfix
status-firefox32: --- → fixed
Depends on: 1013809
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.