From owner-freebsd-current@FreeBSD.ORG  Tue Sep  2 06:51:15 2008
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 96E04106569F;
	Tue,  2 Sep 2008 06:51:15 +0000 (UTC)
	(envelope-from Yuriy.Tsibizov@gfk.com)
Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139])
	by mx1.freebsd.org (Postfix) with ESMTP id B76E68FC17;
	Tue,  2 Sep 2008 06:51:14 +0000 (UTC)
	(envelope-from Yuriy.Tsibizov@gfk.com)
Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0)
	with ESMTP id md50001762409.msg; Tue, 02 Sep 2008 10:51:28 +0400
Received: from bootserv.hhp.local ([10.0.0.54]) by ex.hhp.local with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 10:51:26 +0400
Date: Tue, 2 Sep 2008 10:52:45 +0400 (MSD)
From: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
X-X-Sender: chibis@atwork.home.local
To: Ed Schouten <ed@80386.nl>
In-Reply-To: <20080902063016.GK99951@hoeg.nl>
Message-ID: <20080902104710.S1754@atwork.home.local>
References: <200809011335.m81DZW8b006033@pozo.com>
	<b41c75520809010719pe5a8e19nb32a925f44a80a47@mail.gmail.com>
	<200809011436.m81Eaq2v040141@pozo.com>
	<20080902095229.Y1605@atwork.home.local>
	<20080902063016.GK99951@hoeg.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-OriginalArrivalTime: 02 Sep 2008 06:51:26.0991 (UTC)
	FILETIME=[524361F0:01C90CC8]
X-Spam-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 10:51:28 +0400
	(not processed: message from valid local sender)
X-MDRemoteIP: 10.0.0.30
X-Return-Path: Yuriy.Tsibizov@gfk.com
X-Envelope-From: Yuriy.Tsibizov@gfk.com
X-MDAV-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 10:51:28 +0400
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)
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Sep 2008 06:51:15 -0000

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.