Saw this on crash-stats: bp-f9122be1-204d-4c5a-b49e-f0b5e2120304 Total Virtual Memory 2147352576 Available Virtual Memory 2026246144 System Memory Use Percentage 26% Available Page File 5563899904 Available Physical Memory 2359562240 OOMAllocationSize 72 I looked at several other crash reports for this signature, and they all seem to have plenty of memory available.

Isn't this a dup of bug 709860? There is likely a heap corruption issue or perhaps a jemalloc bug, but it's hard to tell from the set of reports we have so far. See also bug 725280 which is slightly earlier but in the same basic location. I've been looking through the codepaths (nsIOService::Init and nsDNSService::Init) and there isn't anything obviously wrong. I kinda wish we had thread labels, but there certainly isn't anything interesting *running* on the other threads at the time of the abort.

What thread labels are you referring to?

bsmedberg... (In reply to Ted Mielczarek [:ted] from comment #2) > What thread labels are you referring to?

Identifiers saying that thread 1 is the socket transport thread, thread 7 is the GC watchdog thread, etc.

Ah, gotcha. Sadly, AIUI, on Windows that data is not actually stored anywhere.

There's been some work reducing address space fragmentation in the interim, so hopefully this is not as much of an issue any more.