Closed Bug 586205 Opened 14 years ago Closed 14 years ago

e10s redirects test test_event_sink_wrap.js failure on Linux.


(Core :: Networking, defect)

Not set





(Reporter: jst, Assigned: mayhemer)



The e10s redirects patch (bug 536294) landed on e10s today and left one test failing seemingly consistently, but only on linux. The failure is:

TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/electrolysis_fedora-debug_test-xpcshell/build/xpcshell/tests/test_necko/unit_ipc/test_event_sink_wrap.js | test failed (with xpcshell return code: 0), see following log:
child: TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/electrolysis_fedora-debug_test-xpcshell/build/xpcshell/tests/test_necko/unit/test_event_sink.js | Should not get any data! - See following stack:

In order to leave the code in place to get more testing on this stuff it was decided to disable this test and file this followup bug to track this issue.

For more details, see:

We only added this test with the e10s redirects patch, but I think the error is possibly from the async redirect API changes.  What we're seeing is that the test has a redirect observer throw NS_BINDING_ABORTED, and then it checks to see that OnData isn't getting called.  But it is getting called, so we must not be cancelling correctly.

To make things more confusing, we're seeing different results in different places.  Both JST and I only see test_event_sink_wrap.js fail (ie only the e10s version), but tinderbox also sees regular test_event_sink.js fail:

Not sure what's going on.

Disabled test for now.

This might just be that we don't have cancel logic in place yet.
Sorry, wrong tinderbox link.  Here's the right one:

Weird that this happens only on linux, and only _wrap fails on some systems.
Looks like this is likely getting fixed by the fix for bug 536317.
(In reply to comment #4)
> Looks like this is likely getting fixed by the fix for bug 536317.

Agree.  And to explain:

Redirect handlers at the bottom of the test are putting a body to the response.  When the redirect is canceled we do ProcessNormal with the response - i.e. we *must get OnDataAvailable* called!

The reason why we have not to get OnDataAvailable is that OnStartRequest on the content process throws Components.results.NS_ERROR_ABORT, that have to cancel the channel load.  But this exception doesn't currently get propagated to the parent because we lack Cancel implementation.

Changing dependencies.
Depends on: 536317
No longer depends on: 536294
Fixed on e10s, then; just needs to get re-enabled when we merge to m-c.
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.