ccall segfault on adopt_threads on win32

[vtjnash]

Been seeing this sometimes on CI lately. At first I assumed it was an OOM, but the backtrace doesn't really align well with that hypothesis, so this probably needs to be looked into more closely.

      From worker 9:
      From worker 9:	Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
      From worker 9:	Exception: EXCEPTION_ACCESS_VIOLATION at 0x746ed01d -- jl_makecontext at C:/workdir/src\win32_ucontext.c:61
      From worker 9:	in expression starting at C:\buildkite-agent\builds\win2k22-amdci6-2\julialang\julia-master\julia-1aa59a6e07\share\julia\test\ccall.jl:1066
      From worker 9:	jl_makecontext at C:/workdir/src\win32_ucontext.c:61
      From worker 9:	jl_init_root_task at C:/workdir/src\task.c:1559
      From worker 9:	ijl_adopt_thread at C:/workdir/src\threading.c:407
      From worker 9:	unknown function (ip: 3b4ce4af)
      From worker 9:	jl_work_wrapper at C:/workdir/src\jl_uv.c:987
      From worker 9:	uv__queue_work at /workspace/srcdir/libuv\src\threadpool.c:305
      From worker 9:	worker at /workspace/srcdir/libuv\src\threadpool.c:122
      From worker 9:	uv__thread_start at /workspace/srcdir/libuv\src/win\thread.c:111
      From worker 9:	beginthreadex at C:\Windows\System32\msvcrt.dll (unknown line)
      From worker 9:	endthreadex at C:\Windows\System32\msvcrt.dll (unknown line)
      From worker 9:	BaseThreadInitThunk at C:\Windows\System32\KERNEL32.DLL (unknown line)
      From worker 9:	RtlGetFullPathName_UEx at C:\Windows\SYSTEM32\ntdll.dll (unknown line)
      From worker 9:	RtlGetFullPathName_UEx at C:\Windows\SYSTEM32\ntdll.dll (unknown line)
      From worker 9:	Allocations: 406330629 (Pool: 406147582; Big: 183047); GC: 1166
Worker 9 terminated.

https://buildkite.com/julialang/julia-master/builds/18112#01845e6d-fc91-4a03-b508-5c3a2afbd063

[vtjnash]

Looking closer, this is the first memory write that should be going to the newly allocated stack for the backup copy-stack context. It should be 0x20 bytes from the very end of it. It should be 8MB large. We have about 2GB allocated in this process already at this time.

That seems to align with being an OOM, but we should defer allocation of the first copy-stack for a new thread until we are actually forced to need it. Many foreign threads probably won't make new tasks that would need to use it.

[giordano]

@vtjnash long shot, but since this involves threading can this possibly be fixed by #50135? Also #48907 reported an EXCEPTION_ACCESS_VIOLATION error, but I don't know if this test would involve libgomp at any point. If anything, this ticket was opened a week after #45582 was merged, so that'd match the "lately" part.

[vtjnash]

It had been ongoing for awhile before I opened this

[vtjnash]

Fixed by #49082