Daniel Kegel wrote:
efrias@syncad.com wrote:
http://bugs.winehq.org/show_bug.cgi?id=2609[Proposed fix:] struct rlimit address_limits; int required_address_space = 1024 * 1024 * 1400; /* 1400M */ getrlimit(RLIMIT_AS, &address_limits); if (address_limits.rlim_max < required_address_space) WINE_WARN("Your virtual memory limit is set to %dk, which will\nprobably prevent wine from loading correctly. If you get an error,\nincrease the limit with 'ulimit -v' to at least %dk.\n", address_limits.rlim_max / 1024, required_address_space / 1024);
Looks groovy to me. But it will completely annoy people using 2.4 kernels, which by default have only 896MB of user address space, won't it? (I may be confused here, but that's what I remember.)
Hm... I hadn't heard of this. But I have to admit, I don't have a very good grasp of what is going on in wine that causes it to need over a gig of address space. I think this patch is safe, since it just reports the user-imposed limits, and not what the system actually makes available. To make sure, I just tested on RedHat 7.2, 8, 9, and Fedora Core 3, and they all have the same behavior: they return the limit you've set with 'ulimit -v', or -1 (RLIM_INFINITY) if no limit has been set. That covers the 2.4 and 2.6 series kernels.
So I guess my test above was incorrect -- it should have been: if (address_limits.rlim_max != RLIM_INFINITY && address_limits.rlim_max < required_address_space)
So I'd encourage you to submit a patch to do this, but only after testing on Red Hat 9.0 to make sure I'm wrong :-)
I'll get a patch ready once I understand a bit more of what is going on that is causing wine to reserve this memory. I'd love to figure out how to get rid of the hard-coded constant, because it looks like it's not going to be big enough for some apps, but it'll be too large for others. It's probably still better than nothing, but I'd rather do it right if that's possible.
Eric