Date: Tue, 2 Sep 2008 10:52:45 +0400 (MSD) From: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru> To: Ed Schouten <ed@80386.nl> Cc: ports@freebsd.org, Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>, FreeBSD Current <freebsd-current@freebsd.org>, Claus Guttesen <kometen@gmail.com> Subject: Re: /usr/bin/limits (WAS: Re: Apache.sh on current) Message-ID: <20080902104710.S1754@atwork.home.local> In-Reply-To: <20080902063016.GK99951@hoeg.nl> References: <200809011335.m81DZW8b006033@pozo.com> <b41c75520809010719pe5a8e19nb32a925f44a80a47@mail.gmail.com> <200809011436.m81Eaq2v040141@pozo.com> <20080902095229.Y1605@atwork.home.local> <20080902063016.GK99951@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Sep 2008, Ed Schouten wrote: > * Yuriy Tsibizov <Yuriy.Tsibizov@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080902104710.S1754>