https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #21 from Zeb Figura z.figura12@gmail.com --- Hmm, the log from comment 17 doesn't quite match what you reported wrt the virtual memory size increasing by 20 MB each time. There are a couple increases but not enough for me to be sure of where they're coming from.
I think it's pretty clear that we're running out of memory, especially given the maps file from comment 20 at the time of the crash, but I'm still not confident of why. The amount of mapped GPU memory is 418 MiB, which is not so high as to be a smoking gun, but the rest of it is anonymous.
Here's what I can tell from analyzing the +virtual log and map files from comment 20:
* the low "reserved" area of 0 - 0x20000000 is not much fuller at crash time than it is at open time;
* also, NtAllocateVirtualMemory only ever returns memory inside that reserved area (with I think one exception, but that memory is freed);
* amount of mapped GPU memory (/dev/renderD128) is higher at crash time than open time, but not really so high as to be a smoking gun (418 MiB vs 342 MiB);
* amount of anonymous mapped memory in the non-reserved area (0x20000000 - 0x7f000000) is way higher at 'crash' time than 'open' time.
So I think that whatever memory is being leaked, is not being allocated by the Wine side. This doesn't necessarily mean that it's not Wine's fault it's being leaked (and I would probably assume it is Wine's fault), but it is useful information nonetheless.
I think this means we can rule out d3d memory; sysmem should go through NtAllocateVirtualMemory, and GPU memory *should* be DMA mapped. Unless radeonsi is ever going to give us anonymous mapped memory?
I'll have to think about how to narrow it down further, though.