Closed Bug 1207938 Opened 10 years ago Closed 8 years ago

Intermittent test_window_open_close.html | application timed out after 330 seconds with no output

Categories

(Core :: IPC, defect, P3)

Product:
Core
Component:
IPC
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: nigelb, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed:other])

No description provided.
Bill, can you take a look at this?
Flags: needinfo?(wmccloskey)
Sorry, I don't work on Android.
Flags: needinfo?(wmccloskey)
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Summary: Intermittent test_window_open_close.html | application timed out after 330 seconds with no output | application crashed [@ libc.so + 0x1c3dc] → Intermittent test_window_open_close.html | application timed out after 330 seconds with no output
this has been failing for the last month and picked up, primarily on linux opt/asan- all in e10s mode. :billm, I see you are the triage owner for core::ipc, could you help look into this bug or find someone who could give the high failure rate?
Flags: needinfo?(wmccloskey)
Whiteboard: [stockwell needswork]
I think this should be fixed by bug 1378374 (which now has a patch). Andrew, one thing that worries me here is that some of the logs contain an ASAN UAF message, but we only seem to be turning the test orange because of the timeout [1]. It's possible it would have been orange anyway somehow, but I just want to make sure. Can you check and make sure everything with ASAN tests is working the way it's supposed to? [1] Example: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=756aa07a185219e8340a196ad215fcd2d5b4d349&selectedJob=117835024
Flags: needinfo?(wmccloskey) → needinfo?(ahalberstadt)
Good catch, I don't think that would turn the job orange. Adding a regex to match that here should do it though: https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/testing/errors.py#115 Does this mean asan has been broken all along? We have mochitest selftests now, if there's a way to reliably reproduce an AddressSanitizer error from a test, we should add a check for that along with this fix. (In reply to Bill McCloskey (:billm) from comment #17) > Can you check and make sure everything with ASAN > tests is working the way it's supposed to? How are they supposed to work? Should any line with the substring "ERROR: AddressSanitizer" be a failure? Here's a try run with that change: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f06adacf7fa6275a44022c632d1eff4b22b627b5
Flags: needinfo?(ahalberstadt)
See Also: → 1385311
Whiteboard: [stockwell needswork] → [stockwell fixed:other]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.