Closed Bug 1094563 Opened 10 years ago Closed 9 years ago

assert ip networking only from parent

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: mcmanus, Assigned: mcmanus)

Details

Attachments

(1 file)

when creating an ip based socket, assert that it is happening from the parent.

Sandboxing is really used to enforce this, this is just a debug only assert to get good stack information on anything that tries to violate it.
Attachment #8517880 - Flags: review?(jduell.mcbugs)
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Comment on attachment 8517880 [details] [diff] [review]
assert necko ip connections made in parent

Review of attachment 8517880 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/base/src/nsSocketTransport2.cpp
@@ +1204,5 @@
> +#ifdef DEBUG
> +        // all IP networking has to be done from the parent
> +        if (NS_SUCCEEDED(mCondition) &&
> +            ((mNetAddr.raw.family == AF_INET) || (mNetAddr.raw.family == AF_INET6))) {
> +            MOZ_ASSERT(!IsNeckoChild());

I suspect we want MOZ_RELEASE_ASSERT here: my impression is that our people rarely run debug builds of the phone (they're too slow), and our test coverage will be stronger if we're also asserting on builds that people are dogfooding, not just automated tests (ex: if people try to use FTP and it somehow tried to do networking on the child).  But I can live with just MOZ_ASSERT if the possibility of crashing consumers' phones is too scary for you :)

Maybe we could MOZ_RELEASE_ASSERT but only on aurora/beta, not release?  The #ifdef DEBUG here would need to go away, of course.
Attachment #8517880 - Flags: review?(jduell.mcbugs) → review+
I'm going to stick with debug only for the moment.. tbpl coverage at least.
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/3c0bba4064b6
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
How do extensions that implement protocol handlers get around this? I have a working E10S version of OverbiteFF, but it hits this assertion in debug builds.

Since the protocol handler has to be implemented in the child, and the child is the one that gets called, is the expectation that the child handler asks the parent to do all its socket I/O for it? Does the child have to pass all events, like onDataAvailable, etc., to the parent?
You need to log in before you can comment on or make changes to this bug.