==

 <System>
   <Provider Name="Application Error" />
   <EventID Qualifiers="0"> 1000 </ EventID>
   <Level> 2 </ Level>
   <Task> 100 </ Task>
   <Keywords> 0x80000000000000 </ Keywords>
   <TimeCreated SystemTime="2013-03-09T15:51:43.000000000Z" />
   <EventRecordID> 26641 </ EventRecordID>
   <Channel> Application </ Channel>
   <Computer> I5-750 </ Computer>
   <Security />
 </ System>
 <EventData>
   <Data> Firefox.exe 
   <Data> 19.0.2.4816 
   <Data> 513b4b90 
   <Data> Unknown 
   <Data> 0.0.0.0 
   <Data> 00000000 
   <Data> C0000005 
   <Data> 004006f2 
   <Data> 2068 
   <Data> 01ce1cdd33ea4c76 
   <Data> D: \ mozilla \ obj \ dist \ bin \ firefox.exe 
   <Data> Unknown 
   <Data> 3c9ae912-88d1-11e2-813b-ff6189ea1304 
 </ EventData>

// It's tempting to see whether we have enough free virtual address space for
 // this allocation and, if we don't, synchronously fire a low-memory
 // notification to free some before we allocate.
 //
 // Unfortunately that doesn't work, principally because code doesn't expect a
 // call to malloc could trigger a GC (or call into the other routines which
 // are triggered by a low-memory notification).
 //
 // I think the best we can do here is try to allocate the memory and check
 // afterwards how much free virtual address space we have.  If we're running
 // low, we schedule a low-memory notification to run as soon as possible.

 // Don't call CheckMemAvailable for MEM_RESERVE if we're not tracking low
 // virtual memory.  Similarly, don't call CheckMemAvailable for MEM_COMMIT if
 // we're not tracking low physical memory.
 if ((sLowVirtualMemoryThreshold != 0 && aAllocationType & MEM_RESERVE) ||
     (sLowPhysicalMemoryThreshold != 0 && aAllocationType & MEM_COMMIT)) {
   LOG3("VirtualAllocHook(size=", aSize, ")");
   CheckMemAvailable();
 }

Private build Firefox 19.0.2 startup crah with MOZ_PROFILE_GENERATE=1 Source Code : Firefox 19.0.2 without any patch. == mozconfig == mk_add_options MOZ_MAKE_FLAGS="-j4" mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj ac_add_options --disable-updater ac_add_options --disable-update-channel ac_add_options --disable-update-packaging ac_add_options --disable-maintenance-service ac_add_options --enable-crashreporter ac_add_options --enable-debug ac_add_options --disable-installer ac_add_options --enable-tests ac_add_options --enable-jemalloc ac_add_options --enable-optimize="-O2i -GL -GS-" # M$VC 2010 ac_add_options --enable-application=browser ==== == windows event log == The name of the log file: Application Source: Application Error Date: 2013/3/9 afternoon 11:51:43 Event ID: 1000 Category: (100) Level: error Keywords: traditional User: NA Computer: i5-750 Description: Faulting application name: firefox.exe, version: 19.0.2.4816, time stamp: 0x513b4b90 The failed module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Error displacement: 0x004006f2 Failure handler ID: 0x2068 Faulting application start time: 0x01ce1cdd33ea4c76 The failed application path: d: \ mozilla \ obj \ dist \ bin \ firefox.exe Failed module path: unknown Report ID: 3c9ae912-88d1-11e2-813b-ff6189ea1304 Event Xml: <Event Xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Application Error" /> <EventID Qualifiers="0"> 1000 </ EventID> <Level> 2 </ Level> <Task> 100 </ Task> <Keywords> 0x80000000000000 </ Keywords> <TimeCreated SystemTime="2013-03-09T15:51:43.000000000Z" /> <EventRecordID> 26641 </ EventRecordID> <Channel> Application </ Channel> <Computer> I5-750 </ Computer> <Security /> </ System> <EventData> <Data> Firefox.exe </ Data> <Data> 19.0.2.4816 </ Data> <Data> 513b4b90 </ Data> <Data> Unknown </ Data> <Data> 0.0.0.0 </ Data> <Data> 00000000 </ Data> <Data> C0000005 </ Data> <Data> 004006f2 </ Data> <Data> 2068 </ Data> <Data> 01ce1cdd33ea4c76 </ Data> <Data> D: \ mozilla \ obj \ dist \ bin \ firefox.exe </ Data> <Data> Unknown </ Data> <Data> 3c9ae912-88d1-11e2-813b-ff6189ea1304 </ Data> </ EventData> </ Event> == dump by vs2010 & binary with enable-debug can download from here: https://docs.google.com/folder/d/0BxHqn7o9vZBaNnRNdWdBdW4yM3M/edit vs2010 debug show "AvailableMemoryTracker.cpp" == // It's tempting to see whether we have enough free virtual address space for // this allocation and, if we don't, synchronously fire a low-memory // notification to free some before we allocate. // // Unfortunately that doesn't work, principally because code doesn't expect a // call to malloc could trigger a GC (or call into the other routines which // are triggered by a low-memory notification). // // I think the best we can do here is try to allocate the memory and check // afterwards how much free virtual address space we have. If we're running // low, we schedule a low-memory notification to run as soon as possible. here -=-=> LPVOID result = sVirtualAllocOrig(aAddress, aSize, aAllocationType, aProtect); // Don't call CheckMemAvailable for MEM_RESERVE if we're not tracking low // virtual memory. Similarly, don't call CheckMemAvailable for MEM_COMMIT if // we're not tracking low physical memory. if ((sLowVirtualMemoryThreshold != 0 && aAllocationType & MEM_RESERVE) || (sLowPhysicalMemoryThreshold != 0 && aAllocationType & MEM_COMMIT)) { LOG3("VirtualAllocHook(size=", aSize, ")"); CheckMemAvailable(); } ==