I have the same problem as you.
I encountered the problem in xulRunner 31.
At this point, I compiled Xulrunner 32 and TCPSocket doesn't seem to work.
For now, I have to disable optimize flag to make things work.
I'm working on MSWINDOWS.

I suspect the original intention of nsMultiplexInputStream was that you would set it up just so, then you would process it, and then you would drop your references to it whenever you stop caring about it. We're using it as an ongoing queue of streams, however, so that's a bit of a problem. My original thought was just to throw a lock into the mix and move on, but there's a lot of shared, mutating state that looks hairy to lock efficiently. I'm going to ponder a mechanism more suitable to our requirements and whether that would be less work and/or more correct.

If the core of TCPSocket weren't implemented in JS we could always do the append on the necko network thread via runnable dispatch. (Or if the multiplex stream did that itself after it had been activated and if it wasn't on the network thread.)
Another possible partial mitigation for the worst of this would be to call SetCapacity on the multiplex stream to a large enough number initially that it should never actually expand need to dynamically resize the array. It seems like there's likely to still be races on the concurrent array access, but at least it wouldn't involve new memory allocations / freed memory allocations in the nsTArray itself.

It just occurred to me that because the actual data sending happens in the parent process in e10s mode, a segfault will take the root b2g process down and that could constitute a DoS security bug. (Originally I wasn't thinking things through and believed that because the tcp-socket API was privileged and subprocesses were the vulnerable ones, so we were safe.) So marking to get triaged.
The specific the specific attack would be something like this.
Prereqs:
- The user is using a legitimate app that uses TCPSocket. For example the built-in email app or the loqui IM app for Firefox OS (https://github.com/loqui/im). These apps tend to have some combination of auto-connection (ex: periodic email sync) and auto-reconnection (ex: email has some exponential backoff stuff with one immediate retry on connection reuse primarily to deal with stale network connections to compensate for the network stack's crappy TCP keep-alive settings as they relate to TCPSocket.)
- Attacker has the ability to passively notice the connection (to see TCP connections) and some ability to reset the connection (via TCP reset or knocking the device off wi-fi) to cause the device to reconnect.
Attack:
- The attacker keeps resetting the TCP connections to try and cause the nsMultiplexStream vulnerability window to trigger and crash the root b2g process.
- In the case mozAlarms are used to launch the vulnerable app, this could result in the phone ending up in the same situation again soon, depending on the alarm interval. mozAlarms fires all alarms that were in the past when it starts up. The email app supports a maximum interval of every 5 minutes; other apps like IM apps may be more aggressive.

This problem is really annoying for my xulrunner application (on microsoft Windows).
At this point, I can't use the optimized version.
Cc["@mozilla.org/tcp-socket;1"].createInstance(Ci.nsIDOMTCPSocket)
is no longer reliable for my work.

I agree we need to resolve this. As a temporary workaround, you might be able to issue multiple .send() calls in rapid succession when you first open the socket (possibly even zero-length?), forcing the array to perform all of its reallocations up-front. Of course, this may also just immediately crash the application instead. In a non-e10s situation this may turn out okay, but the latency of the messages in the e10s case may increase the probability of collision/explosion too much.

Any hope to investigate this ? It's blocking me badly to create a new tool that makes intensive use of ADB pull and I do have 100% repro on the crash in my case (need two addons and specific devices though for now).

My best idea so far is to create a new C++ class like this:
class nsThreadsafeMultiplexInputStream : public nsIMultiplexStream
, public nsISeekableStream
, public nsIIPCSerializableStream
{
Mutex mLock;
nsCOMPtr<nsIMultiplexStream> mStream;
public:
NS_DECL_THREADSAFE_ISUPPORTS
NS_DECL_NSIMULTIPLEXSTREAM
NS_DECL_NSISEEKABLESTREAM
NS_DECL_NSIIPCSERIALIZABLESTREAM
};
Every method would first lock mLock before calling through to mStream. This wouldn't guarantee perfect threadsafety (due to the single use of the `this` pointer in nsMultiplexStream::ReadSegments) but it should be enough to avoid the crash exhibited here.

Comment on attachment 8604631[details][diff][review]
Add a threadsafe wrapper for persistent nsMultiplexStream queues
Review of attachment 8604631[details][diff][review]:
-----------------------------------------------------------------
And trust me, if I could put more '+' on this 'f', I would. This has fixed the issue for me so far: while the code was crashing nearly instantaneously when doing my set of adb pull (850+ files to get from the device), I have now been able to complete more than 5 consecutive full run of pulling, without hitting a single crash. Thank you so much for the fast workaround!

Comment on attachment 8604631[details][diff][review]
Add a threadsafe wrapper for persistent nsMultiplexStream queues
Nathan, what do you think about this solution? It looks like TCPSocket is using nsMultiplexInputStream in a different way than it way originally intended (a dedicated queue of streams vs. a fire-and-forget collection of multiple streams), hence the threading issues that we ran into. This is the most naive locking behaviour possible because the ReadSegments code is pretty hairy to pull apart.

To reword comment 16, the theory is that nsMultiplexInputStream was meant to be used like:
1. make nsMultiplexInputStream
2. appendStream a bunch of things
3. drain the stream entirely
But this different usage is constantly calling appendStream and removeStream as new streams show up or are emptied? Is that correct?

(In reply to Josh Matthews [:jdm] from comment #27)
> User impact if declined: Intermittent crashes in certain b2g apps such as
> the email client.
For clarity, the crash will occur in the root/parent b2g process, since that's where the actual crashy network code is running. This is notable because it's much worse than just the app process crashing.

Comment on attachment 8604631[details][diff][review]
Add a threadsafe wrapper for persistent nsMultiplexStream queues
This fix has been on mozilla-central for over a week and has not had a negative impact that we know of. Approving for uplift to Beta and Aurora.