BrowserSubProcess - Increase X64/ARM64 stack size

[amaitland]

Reports suggest DevTools requires a larger stack size

https://bitbucket.org/chromiumembedded/cef/issues/3250/devtools-crash-when-inspecting-deeply#comment-61774526

Check chrome.exe stack size for reference

https://myprogrammingnotes.com/check-set-stack-size-limit-qt-applications.html
https://bitbucket.org/chromiumembedded/cef/issues/3252/nested-hang-on-cefsimple#comment-61787323

• Validate stack size for both arm64 and x64
• Validate strong name after stack size change

[amaitland]

if (current_cpu == "x86") {
        # Set the initial stack size to 0.5MiB, instead of the 1.5MiB needed by
        # Chrome's main thread. This saves significant memory on threads (like
        # those in the Windows thread pool, and others) whose stack size we can
        # only control through this setting. Because Chrome's main thread needs
        # a minimum 1.5 MiB stack, the main thread (in 32-bit builds only) uses
        # fibers to switch to a 1.5 MiB stack before running any other code.
        ldflags = [ "/STACK:0x80000" ]
      } else {
        # Increase the initial stack size. The default is 1MB, this is 8MB.
        ldflags = [ "/STACK:0x800000" ]
      }

[amaitland]

https://source.chromium.org/chromium/chromium/src/+/main:chrome/app/chrome_exe_main_win.cc;l=245?q=CreateFiberEx&ss=chromium

[amaitland]

The stack size for x64 will be updated first as it's a straight forward change.

Both project files will need to be updated:

• https://github.com/cefsharp/CefSharp/blob/cefsharp/98/CefSharp.BrowserSubprocess/CefSharp.BrowserSubprocess.csproj#L38

The netcore project doesn't have a editbin entry, have to double check as to the reason that wasn't included.

[amaitland]

x64 and arm64 should both now have an 8mb stack size. Will need to validate both before release as arm64 have stopped working for me locally after installing VS2022.

[amaitland]

Renaming issue as I'm not planning on increasing the x86 stack size as part of this issue.

[amaitland]

The exes in the 100.0.120-pre release appear to have their values set correctly. They're all TSAware, LargeAddressAware for the x86 builds, the .Net 4.5.2 exes are strongly named. The .Net Core exes aren't (which is expected as it's a bootstrapper exe for the dll of same name). The .Net Core x86 exe appears to already have a slightly bigger stack size.

Closing as this appears to be complete.