Closed Bug 1204578 Opened 9 years ago Closed 9 years ago

test_osfile_comms.xul fails on Linux debug after DevTools file move

Categories

(Toolkit Graveyard :: OS.File, defect)

43 Branch
defect
Not set
normal

Tracking

(firefox43 affected)

RESOLVED WONTFIX
Tracking Status
firefox43 --- affected

People

(Reporter: jryans, Unassigned)

References

Details

In bug 912121, I am moving all DevTools files up to /devtools. I am currently blocked on a test failure in OS.File that seems unrelated to my changes. On Linux 32 & 64 (debug only, opt is fine), the test test_osfile_comms.xul permafails. Other platforms are fine for both debug and opt. Here's an example try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e0538032d629 I've added a few logging states to the test and also tried forcing the worker to terminate, but that has not helped. It's strange, because the test does call finish(), but the harness then claims the test timed out.
Yoric, are you able to spot what's going wrong here?
Flags: needinfo?(dteller)
I've found that it is a conflict with DevTools tests running before this one, as disabling all DevTools chrome tests fixes the issue. Currently continuing to bisect the test dirs to learn more. If only it would repro locally... :(
I can't see anything obviously wrong. Perhaps one of the DevTools tells is injecting something on workers? I'd suggest finding out if DevTools does something fishy that could possibly reveal/hide a bug, but if this is too much of an annoyance, I can try and port this test to a xpcshell test. It was written as a mochitest before xpcshell had access to workers.
Flags: needinfo?(dteller)
After several days of pulling my hair out on try, I've isolated the DevTools test responsible, so I'll just disable it: test_devtools_extensions.html So we can leave this test as is.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.