Open Bug 1982752 Opened 1 year ago Updated 4 months ago

Crash in [@ stackoverflow | OnThreadExit]

Categories

(Core :: Security: Process Sandboxing, defect, P3)

Other
Windows
defect

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
Component: General → Security: Process Sandboxing

Can you help with triage, please?

Flags: needinfo?(bobowencode)

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

Severity: -- → S3
Flags: needinfo?(bobowencode)
Priority: -- → P3
See Also: → 1958276

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.

You need to log in before you can comment on or make changes to this bug.