https://bugs.winehq.org/show_bug.cgi?id=55818
--- Comment #26 from Tom M tmwine@pertho.net --- (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!
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.