Closed Bug 1356377 Opened 9 years ago Closed 9 years ago

Intermittent dom/security/test/mixedcontentblocker/test_bug803225.html | Test timed out.

Categories

(Core :: DOM: Security, defect, P3)

Product:
Core
Component:
DOM: Security
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: bulk-close-intermittents, intermittent-failure, Whiteboard: [domsecurity-intermittent])

These seem to have started after bug 1356193 landed on autoland.
Depends on: 1356193
Flags: needinfo?(gijskruitbosch+bugs)
Per the screenshot, the tab is crashing. I have no idea why it would do that as a result of this change. My best guess is some kind of bizarre compiler optimization, or me somehow misunderstanding how 'auto' works. Otherwise the change shouldn't have had any effects at all. :-\ Is there some way to get the content crash stack here? I see there's .dmp artifacts for these jobs but no stacks in the logs, and I'm unsure how to get a stack out of the dump given the OS, build etc. mismatches... Chris, does treeherder have some kind of tools to do something useful with the .dmp files?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(cmanchester)
We're supposed to be logging the crash stacks for child and parent processes and symbolicating them with mozcrash, which doesn't seem to be happening for some of those runs, although I did find a pair of stacks logged in https://treeherder.mozilla.org/logviewer.html#?job_id=91412612&repo=autoland&lineNumber=6594 I don't know how useful those are but at any rate with a few more retriggers I can see the failure in the push prior to Gijs' via the link in comment 2.
Flags: needinfo?(cmanchester)
Priority: -- → P3
Whiteboard: [domsecurity-intermittent]
Status: NEW → RESOLVED
Closed: 9 years ago
Keywords: bulk-close-intermittents
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.