https://bugs.winehq.org/show_bug.cgi?id=53217
--- Comment #6 from Zeb Figura z.figura12@gmail.com --- (In reply to Zeb Figura from comment #5)
debian11 no longer suffers from this, but gitlab still does.
This is strange. The crash location is clearly a matter of out-of-memory, but the test is not exactly memory-hungry. It might be the most memory-hungry of all the d3d tests, but even then, it shouldn't use that much memory. I can VirtualAlloc() 3/8 of the available address space before running and it's still fine here.
I'm reminded of bug 55283, which is also about us somewhat surprisingly running into memory limits in the gitlab CI (and nowhere else).
I don't think that gitlab is crashing in this function precisely. Actually at least d3d11 seems to be crashing in test_resource_access(), but it may not be consistent.
I've been trying to dump /proc/self/maps to see where all the space is being taken up. By analyzing the size of mapped ranges, I notice a lot more areas with mapped sizes of 0x800000, which I believe is the default pthread stack size. These aren't Wine threads; there's only three of those around at the time of the crash. On my local machine there are 25 pthreads; on gitlab there are a whole 65.
So what are these pthreads? One thing I notice is that llvmpipe will, by default, spawn $(nproc) threads for rasterization. I have 12 CPUs on this machine; I don't know how many are on gitlab. But that's capped at 32, so that can't explain all of it. Something else in Mesa, perhaps?
How many CPUs does the gitlab machine have? Anyone know the answer to that question?