https://bugs.winehq.org/show_bug.cgi?id=53711
--- Comment #16 from Zeb Figura z.figura12@gmail.com --- (In reply to pandora.xero from comment #15)
Ran it until it crashed - here's the output from top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18065 xero 20 0 4174044 497084 94132 S 0.0 0.8 125:46.42 pol.exe
VIRT jumps about 20MB every time I switch characters.
My baseline on Windows only went as high as about 320MB Used - but I'm guessing that number only reflects the equivalent of the RES column here - and that was after much more activity, much more play time, and many more character changes.
I'm unsure as to what's causing VIRT to balloon in size like so. I don't know if this is a factor or not, but the system in question has no swap partition/file, and 64GB of RAM total.
Hmm, interesting. That's a clear sign of a leak, but I'm not immediately sure where. Conveniently, it does mean that it's easier to debug this, because we don't actually need to wait until things crash, but can instead just switch characters a couple of times :-)
20 MB would *not* be consistent with wined3d chunk allocation, since those chunks are 64 MB in size. Of course, it could still be related to d3d, but it's less obvious how.
So here's something that would be helpful to try, if you would. Start wine with WINEDEBUG=+virtual,+pid,+timestamp (redirecting the output to a log file), then do this:
(1) cat /proc/<pid>/maps > maps1 (2) change characters
Repeat this a few times, copying maps into a new file every time; then tar everything up and attach it here.
The idea here is to figure out what's being mapped anew and where. If it's a file or GPU memory, it should be evident, and provide a good hint as to what's leaking it, and if it's anonymous, we should hopefully make it easier to narrow down in Wine where it's coming from.
Thanks!