Yes, test_cube_maps() has unusual usage patterns; all of our d3d tests do. In a very general sense, realistic usage patterns are great to test, but not all results can be tested the most efficiently that way, and some are kind of impossible to test in a realistic manner.
If we were simulating a real application we would be presenting to a swapchain, and we would not be constantly reading back GPU textures. Both of these things contribute to test_cube_maps() running out of memory (presentation submits a command buffer in d3d which triggers garbage collection, readback consumes CPU memory). But adding presentation would slow down the test and distract from it, and we fundamentally *can't* test that things work without readback.
Also, a real application would usually not be using a software renderer, which takes up a lot more CPU memory by virtue of (a) spawning CPU threads to do the work that the GPU normally does, (b) storing textures in CPU memory that are normally in GPU memory.
It's also worth mentioning that, at least in the case of test_cube_maps(), the unusual usage patterns only end up contributing to a small part of the total address space usage. Much of the rest is out of our control. Some of it can maybe be addressed upstream, if we can convince Mesa to care about 32-bit applications, but it will take forever to propagate to our test VMs, and CI will simply be broken until then. Some of it can't (I do not in a million years expect we will ever be able to do anything about LLVM). Most other solutions will take a lot of effort that just doesn't seem worthwhile for tests.
And yes, fundamentally, increasing the amount of available address space means that real leaks are less likely to show up. But that's true no matter how we increase it. Trying to increase it a little bit, so that we have *just enough* address space available, seems like the kind of solution that is not going to last very long, and we're going to be right back here again soon enough. I can only feel like it makes more sense to use a larger hammer.