From owner-cvs-all Sat Sep 14 19:25:47 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0207837B400; Sat, 14 Sep 2002 19:25:46 -0700 (PDT) Received: from dilbert.robbins.dropbear.id.au (137.c.002.mel.iprimus.net.au [203.134.135.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CBA43E6E; Sat, 14 Sep 2002 19:25:44 -0700 (PDT) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au (ur5iahfbz6mlmoyn@localhost [127.0.0.1]) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6) with ESMTP id g8F2PbUD024815; Sun, 15 Sep 2002 12:25:37 +1000 (EST) (envelope-from tim@dilbert.robbins.dropbear.id.au) Received: (from tim@localhost) by dilbert.robbins.dropbear.id.au (8.12.6/8.12.6/Submit) id g8F2PaUL024814; Sun, 15 Sep 2002 12:25:36 +1000 (EST) Date: Sun, 15 Sep 2002 12:25:36 +1000 From: Tim Robbins To: Bruce Evans Cc: Martin Blapp , "Jacques A. Vidrine" , netctar@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/net getaddrinfo.c gethostbydns.c getnetbydns.c name6.c res_query.c res_update.c Message-ID: <20020915122536.A24407@dilbert.robbins.dropbear.id.au> References: <20020914184126.F3162-100000@levais.imp.ch> <20020915050924.G1223-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020915050924.G1223-100000@gamplex.bde.org>; from bde@zeta.org.au on Sun, Sep 15, 2002 at 05:15:27AM +1000 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Sep 15, 2002 at 05:15:27AM +1000, Bruce Evans wrote: > On Sat, 14 Sep 2002, Martin Blapp wrote: > > > > Hmm, I cannot reproduce it. What's your environment? > > > > It's not you fault. Tim J. Robbins and I have reporduced it and he has > > tracked it down to libc_r. > > > > Stack growing is broken in libc_r. Everything that tries to expand the > > stack above 65536 is broken. > > ... > > See testcase: > > > > http://people.freebsd.org/~tjr/stack.c > > > > Important ! This is in STABLE too. > > This seems to be just hitting the default limit: > > %%% > Script started on Sun Sep 15 05:10:34 2002 > ttyv1:root@gamplex:/tmp> ulimit -s > 65536 > ttyv1:root@gamplex:/tmp> ulimit -s 65537 > ttyv1:root@gamplex:/tmp> ulimit -s > 65536 > ttyv1:root@gamplex:/tmp> grep MAXSSIZ /usr/include/machine/*.h > /usr/include/machine/vmparam.h:#ifndef MAXSSIZ > /usr/include/machine/vmparam.h:#define MAXSSIZ (64UL*1024*1024) /* max stack size */ > ttyv1:root@gamplex:/tmp> exit > > Script done on Sun Sep 15 05:10:52 2002 > %%% > > The limit can't be raised above 65536K without changing the (kernel) > compile-time default. Right, I was just testing the symptoms and experimenting with buffer sizes. It crashes if the buffer is >64 kbytes. The crash is either caused by exceeding PTHREAD_STACK_DEFAULT (65536 bytes) or by tricking the redzone allocator by accessing stack variables which are past the red zone. I don't know enough about libc_r's stack management to decide between the two causes. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message