https://bugs.winehq.org/show_bug.cgi?id=55818
--- Comment #27 from Zeb Figura z.figura12@gmail.com --- (In reply to Tom M from comment #26)
(In reply to Zeb Figura from comment #24)
Hmm, okay. When I tested, I did teleport to other areas a couple of times, and it did seem to knock VmSize down by maybe 100 MB each time, but not more than that—like a bit of GC was being done, but the major leak wasn't being cleaned up.
This is what I've seen with both 7.3 and 8.21. You can teleport to different zones, and the VmSize goes down ever so slightly, as you say, 100 MB. I've seen this too. However, it doesn't seem to go far enough in clearing up the memory.
That's interesting actually. Wine doesn't really do GC (ironically, the only real GC we do, at least in d3d, is actually *introduced* by ee1255696. I did make sure to test and we aren't leaking mapped buffers, so that's almost certainly not the problem anyway.)
Ah that's good! It's good to eliminate variables!
What I meant to hypothesize here, but forgot to actually write down is, it's quite possible that these particles are actually still rendered but invisible. If true that suggests the leak is on the game side, which may very well be the case on Windows, but one way or another (possibly accidentally) the game makes sure that the leaked particles aren't visibly rendered.
It's not unlikely that there are multiple problems, which is one of the reasons I've highlighted the possibility that the leak was always present but we simply had more memory to begin with before. Or possibly there are just multiple leaks.
Hrm, but this is definitely a regression, right? Is there a pattern of play for certain that you can say for sure is more likely to trigger a crash with current Wine than earlier Wine? Or something that causes VmSize to grow faster, or to start from a higher point when you enter the game? Identifying that is going to be necessary to bisect or debug.
In the meantime I'm going to remove the bisect result since it's probably incorrect right now.
I think you're right. It is a regression but the bisect result is incorrect now that I've done a lot more testing.
I wish I could test with WINE 6.0, but I can't get it to compile alongside OpenLDAP 2.6.
You can probably just build wine without LDAP support; you're definitely not going to need it for this game. I think the configure argument is --without-ldap but configure --help should tell you for certain.
Alternatively I believe we do serve pre-built packages for development snapshots, and we keep around old builds, so that may be a faster/easier way to get those builds. I don't know how to get them, let alone for your distribution, but https://wiki.winehq.org/Download is probably the place to start looking.