/usr/bin/limits (WAS: Re: Apache.sh on current)

Yuriy Tsibizov Yuriy.Tsibizov at gfk.ru
Tue Sep 2 06:51:15 UTC 2008


On Tue, 2 Sep 2008, Ed Schouten wrote:

> * Yuriy Tsibizov <Yuriy.Tsibizov at gfk.ru> wrote:
>> (gdb) bt
>> #0  0x00000000 in ?? ()
>> #1  0x0804937d in main (argc=3, argv=0xbfbfed44)
>>      at /usr/src/usr.bin/limits/limits.c:341
>>   (gdb) l
>> 341		    val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_cur, limits[rcswhich].rlim_cur);
>> 342		    limits[rcswhich].rlim_cur = resources[rcswhich].func(lc, str, val, val);
>> 343		    /* maximum value overridden by resourcename or resourcename-max */
>> 344		    sprintf(str, "%s-max", resources[rcswhich].cap);
>> 345		    val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_max, limits[rcswhich].rlim_max);
>> 346		    limits[rcswhich].rlim_max = resources[rcswhich].func(lc, str, val, val);
>> 347		}
>> 348		}
>> 349	    }
>> 350
>>   (gdb) p resources
>> $1 = {{cap = 0x804adc2 "cputime", func = 0x8048c84 <login_getcaptime>}, {
>>      cap = 0x804adca "filesize", func = 0x8048c34 <login_getcapsize>}, {
>>      cap = 0x804add3 "datasize", func = 0x8048c34 <login_getcapsize>}, {
>>      cap = 0x804addc "stacksize", func = 0x8048c34 <login_getcapsize>}, {
>>      cap = 0x804ade6 "coredumpsize", func = 0x8048c34 <login_getcapsize>},{
>>      cap = 0x804adf3 "memoryuse", func = 0x8048c34 <login_getcapsize>}, {
>>      cap = 0x804adfd "memorylocked", func = 0x8048c34 <login_getcapsize>},{
>>      cap = 0x804ae0a "maxproc", func = 0x8048c94 <login_getcapnum>}, {
>>      cap = 0x804ae12 "openfiles", func = 0x8048c94 <login_getcapnum>}, {
>>      cap = 0x804ae1c "sbsize", func = 0x8048c34 <login_getcapsize>}, {
>>      cap = 0x804ae23 "vmemoryuse", func = 0x8048c34 <login_getcapsize>}, {
>>      cap = 0x0, func = 0}}
>
> Looks like I introduced this regression when importing MPSAFE TTY.
> limits(1) dies when RLIMIT_NLIMITS is increased, but the array in
> limits.c isn't extended (seems to be quite fragile).
>
> Can you try the attached patch for limits(1)? Thanks!

Will test it this evening, but patch iteslf looks correct.

Yuriy.



More information about the freebsd-ports mailing list