Closed Bug 1377627 Opened 7 years ago Closed 7 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | /fetch/api/redirect/redirect-schemes.html | expected OK

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1387285

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [necko-backlog][stockwell fixed:product])

See Also: → 1326505, 1314834
Whiteboard: [necko-backlog]
See Also: 1326505 → 
Test timeout because content process is crashed.
>Hit MOZ_CRASH(LoadInfo not thread-safe) at /home/worker/workspace/build/src/xpcom/base/nsISupportsImpl.cpp:43

Need to get the full crash stack to understand which usage of LoadInfo is causing this error.
this is failing at the >3 times/day rate- closer to 5x/day.  

here is a recent log:
https://treeherder.mozilla.org/logviewer.html#?repo=autoland&job_id=114979689&lineNumber=3457

:mcmanus, would it be possible to see if there is something simple going on here?
Flags: needinfo?(mcmanus)
both loadinfo and corslistenerproxy are apparently being used by the wrong thread.. but there's no stack.

This is actually not a necko test.. maybe ben has some insight into debug?
Flags: needinfo?(mcmanus) → needinfo?(bkelly)
:mcmanus, thanks for redirecting this properly- do you know what component this test should live in?  I want to make sure we have test cases mapped to the right components so we don't file bugs in the wrong places.
Flags: needinfo?(mcmanus)
fetch api is, right now anyhow, a dom concept.
Flags: needinfo?(mcmanus)
So, the test is exercising code-paths where we fail due to unexpected schemes during redirect.  So nsCORSListenerProxy fails to QI to an http channel since its not http.  This then causes the CORS redirect handler to fail and cancel the channel.  It seems when we cancel the channel here we can end up releasing the channel via a runnable on the wrong thread.

I have no idea what that runnable is without a stack, though.

Joel, can we fix stack reporting for MOZ_CRASH() in content processes in WPT?  I think that would help with other future bugs as well.

Note, we can't just avoid adding the CORS listener here because the request starts as http and tries to redirect to a different scheme.
Flags: needinfo?(bkelly) → needinfo?(jmaher)
:ahal, are you familiar with MOZ_CRASH and wpt much?
Flags: needinfo?(jmaher) → needinfo?(ahalberstadt)
Not really, I could probably do some digging and figure something out, but jgraham could investigate a lot quicker.
Flags: needinfo?(ahalberstadt) → needinfo?(james)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a908f48c3ae934681449ad3d165e2d6311e959fe&selectedJob=117036365 has a fixup in the harness to improve the handling of content crashes.
Flags: needinfo?(james)
Depends on: 1384063
Bug 1387285 has a stack for this now.  The channel is getting released on the SocketTransportThread for some reason which I think lets me play hot potato back to team necko...
Depends on: 1387285
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Whiteboard: [necko-backlog] → [necko-backlog][stockwell fixed:product]
You need to log in before you can comment on or make changes to this bug.