tor-browser

commit e58a7f1be0611ccfb8576736ebbadac07e242a7d
parent 01b0bdb668b05fe24eb81ff3e5a230ac129d7cee
Author: Andrew Osmond <aosmond@gmail.com>
Date:   Mon, 22 Dec 2025 16:19:00 +0000

Bug 2007280 - Limit stack size of RemoteBackbuffer threads to match SwComposite. r=gfx-reviewers,lsalzman

When we are compositing in the parent process, the SwComposite thread
will perform the same operations as RemoteBackbuffer threads inline.
This means its stack size must be sufficient, so we can reduce
RemoteBackbuffer to default to 40kB.

Differential Revision: https://phabricator.services.mozilla.com/D277339

Diffstat:
M
widget/windows/RemoteBackbuffer.cpp
 | 
8
+++++++-

1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/widget/windows/RemoteBackbuffer.cpp b/widget/windows/RemoteBackbuffer.cpp
@@ -396,6 +396,12 @@ bool Provider::Initialize(HWND aWindowHandle, DWORD aTargetProcessId) {
 
   mStopServiceThread = false;
 
+  // This matches the stack size used by the SwComposite thread. If we are
+  // compositing in the parent process, it would perform the same operations
+  // done on RemoteBackBuffer thread, so it should be sufficient. This is likely
+  // rounded up to 64kB on Windows, but much smaller than the default.
+  static constexpr PRUint32 kRemoteBackbufferStackSize = 40 * 1024;
+
   // Use a raw NSPR OS-level thread here instead of nsThread because we are
   // performing low-level synchronization across processes using Win32 Events,
   // and nsThread is designed around an incompatible "in-process task queue"
@@ -403,7 +409,7 @@ bool Provider::Initialize(HWND aWindowHandle, DWORD aTargetProcessId) {
   mServiceThread = PR_CreateThread(
       PR_USER_THREAD, [](void* p) { static_cast<Provider*>(p)->ThreadMain(); },
       this, PR_PRIORITY_NORMAL, PR_GLOBAL_THREAD, PR_JOINABLE_THREAD,
-      0 /*default stack size*/);
+      kRemoteBackbufferStackSize);
   return !!mServiceThread;
 }