I spoke to Yannis about this and he coinfirmed my suspicions that these are all likely to actually be OOMs (see bug 1958276). Other similar bugs have been marked S3. From Yannis: > in https://crash-stats.mozilla.org/report/index/06797cc6-0a02-44a5-95ff-aa1570250725 > > we can see what address (000000a9ba63d000) we were touching when we crashed : > ``` > 0:092> .ecxr > rax=0000000000001830 rbx=000000007ffe0385 rcx=00007ff639630000 > rdx=0000000000000002 rsi=00007ff639632820 rdi=000000007ffe0384 > rip=00007ff63966c817 rsp=000000a9ba63f548 rbp=0000000000000000 > r8=0000000000000000 r9=00007ff639632820 r10=000000a9ba63d000 > r11=000000a9ba63d000 r12=00007ff639632820 r13=00007ffe5856efa0 > r14=0000000000000002 r15=00007ff639630000 > iopl=0 nv up ei ng nz na po cy > cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010287 > firefox!__chkstk+0x37: > 00007ff6`3966c817 41c60300 mov byte ptr [r11],0 ds:000000a9`ba63d000=00 > ``` > and because it's a Nightly crash we can see which memory is allocated to the stack of which thread with !address: > ``` > + a9`ba5c0000 a9`ba5f8000 0`00038000 MEM_PRIVATE MEM_RESERVE Stack [~74; 7324.897c] > a9`ba5f8000 a9`ba5fb000 0`00003000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE | PAGE_GUARD Stack [~74; 7324.897c] > a9`ba5fb000 a9`ba600000 0`00005000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~74; 7324.897c] > + a9`ba600000 a9`ba63b000 0`0003b000 MEM_PRIVATE MEM_RESERVE Stack [~92; 7324.b00] > a9`ba63b000 a9`ba640000 0`00005000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~92; 7324.b00] > + a9`ba640000 a9`ba6ba000 0`0007a000 MEM_PRIVATE MEM_RESERVE Stack [~75; 7324.56fc] > a9`ba6ba000 a9`ba6bd000 0`00003000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE | PAGE_GUARD Stack [~75; 7324.56fc] > a9`ba6bd000 a9`ba6c0000 0`00003000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~75; 7324.56fc] > ``` > > and so we can see that there's still a lot of memory reserved for the thread ~92 that hasn't been touched (0x3b000 = 241664 bytes untouched, out of 0x40000 = 262144 bytes total) so we can exclude the "actual stack overflow case" for this crash dump
Bug 1982752 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I spoke to Yannis about this and he confirmed my suspicions that these are all likely to actually be OOMs (see bug 1958276). Other similar bugs have been marked S3. From Yannis: > in https://crash-stats.mozilla.org/report/index/06797cc6-0a02-44a5-95ff-aa1570250725 > > we can see what address (000000a9ba63d000) we were touching when we crashed : > ``` > 0:092> .ecxr > rax=0000000000001830 rbx=000000007ffe0385 rcx=00007ff639630000 > rdx=0000000000000002 rsi=00007ff639632820 rdi=000000007ffe0384 > rip=00007ff63966c817 rsp=000000a9ba63f548 rbp=0000000000000000 > r8=0000000000000000 r9=00007ff639632820 r10=000000a9ba63d000 > r11=000000a9ba63d000 r12=00007ff639632820 r13=00007ffe5856efa0 > r14=0000000000000002 r15=00007ff639630000 > iopl=0 nv up ei ng nz na po cy > cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010287 > firefox!__chkstk+0x37: > 00007ff6`3966c817 41c60300 mov byte ptr [r11],0 ds:000000a9`ba63d000=00 > ``` > and because it's a Nightly crash we can see which memory is allocated to the stack of which thread with !address: > ``` > + a9`ba5c0000 a9`ba5f8000 0`00038000 MEM_PRIVATE MEM_RESERVE Stack [~74; 7324.897c] > a9`ba5f8000 a9`ba5fb000 0`00003000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE | PAGE_GUARD Stack [~74; 7324.897c] > a9`ba5fb000 a9`ba600000 0`00005000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~74; 7324.897c] > + a9`ba600000 a9`ba63b000 0`0003b000 MEM_PRIVATE MEM_RESERVE Stack [~92; 7324.b00] > a9`ba63b000 a9`ba640000 0`00005000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~92; 7324.b00] > + a9`ba640000 a9`ba6ba000 0`0007a000 MEM_PRIVATE MEM_RESERVE Stack [~75; 7324.56fc] > a9`ba6ba000 a9`ba6bd000 0`00003000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE | PAGE_GUARD Stack [~75; 7324.56fc] > a9`ba6bd000 a9`ba6c0000 0`00003000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~75; 7324.56fc] > ``` > > and so we can see that there's still a lot of memory reserved for the thread ~92 that hasn't been touched (0x3b000 = 241664 bytes untouched, out of 0x40000 = 262144 bytes total) so we can exclude the "actual stack overflow case" for this crash dump