Crash in [@ stackoverflow | OnThreadExit]
Categories
(Core :: Security: Process Sandboxing, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | affected |
People
(Reporter: release-mgmt-account-bot, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/06797cc6-0a02-44a5-95ff-aa1570250725
Reason: EXCEPTION_STACK_OVERFLOW
Top 10 frames of crashing thread:
0 firefox.exe __chkstk /builds/worker/workspace/obj-build/browser/app/D:/a/_work/1/s/src/vctools/crt/vcstartup/src/misc/amd64/chkstk.asm:109
1 firefox.exe OnThreadExit security/sandbox/chromium/base/threading/thread_local_storage_win.cc:62
2 ntdll.dll ImageTlsCallbackCaller
3 ntdll.dll LdrpCallInitRoutineInternal
4 ntdll.dll LdrpCallInitRoutine
5 ntdll.dll LdrpCallTlsInitializers
6 ntdll.dll LdrpInitializeThread
7 ntdll.dll LdrpInitialize
8 ntdll.dll LdrpInitializeInternal
9 ntdll.dll LdrInitializeThunk
By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:
- First crash report: 2025-06-04
- Process type: Parent
- Is startup crash: No
- Has user comments: No
- Is null crash: No
Comment 2•1 year ago
•
|
||
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=00and 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
Comment 3•4 months ago
|
||
This looks a lot like the older bug 1758240. We could probably duplicate there given that these signatures are all likely to be OOM conditions. Note that all these crashes are caught by WER, so they should become quite a bit better once we move main process crash generation into the crash helper.
Description
•