Detecting ulimit problem

[Eric Frias]

Daniel Kegel wrote:
> efrias at 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