Date: Sun, 15 Sep 2002 12:25:36 +1000 From: Tim Robbins <tjr@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: Martin Blapp <mb@imp.ch>, "Jacques A. Vidrine" <nectar@FreeBSD.ORG>, 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> In-Reply-To: <20020915050924.G1223-100000@gamplex.bde.org>; from bde@zeta.org.au on Sun, Sep 15, 2002 at 05:15:27AM %2B1000 References: <20020914184126.F3162-100000@levais.imp.ch> <20020915050924.G1223-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020915122536.A24407>