From owner-freebsd-emulation Thu Sep 7 15:12:11 2000 Delivered-To: freebsd-emulation@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id B175437B42C for ; Thu, 7 Sep 2000 15:12:08 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA25143; Thu, 7 Sep 2000 16:09:30 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id QAA06661; Thu, 7 Sep 2000 16:09:28 -0600 (MDT) (envelope-from nate) Date: Thu, 7 Sep 2000 16:09:28 -0600 (MDT) Message-Id: <200009072209.QAA06661@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bruce Evans Cc: Nate Williams , Andrew Gallatin , marcel@cup.hp.com, freebsd-emulation@FreeBSD.ORG Subject: Re: IBM JDK fails due to lack of SA_SIGINFO support In-Reply-To: References: <200009071533.JAA05353@nomad.yogotech.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > The change you're referring to isn't all that much different that what > > > > I'd been doing previously (setting MINSIGSTKSZ to 2048 in sys/signal.h). > > > > > > It is quite different. You change is not incorrect, but the committed > > > versions of Nate's patch results in memory beyond the end of the stack > > > being clobbered if the stack is actually use. > > > > Ouch. Why is that? I would have thought that the signalstack's were > > 'essentially' unallocated space, so by bumping up the size, we were > > giving the application more space to work with, not less. > > Alternative signal stacks are allocated by the application. And the size is allocated inside the application's space? I thought the size was allocated inside the kernel, hence the need for the system call. > Bumping the size in the kernel corresponds to using unallocated space > beyond the end of the space allocated by the application. So how would you propose fixing this? In Linux, the minimum size is << FreeBSD's minimum size. Either we decrease FreeBSD's minimum size or we abort the request, causing these applications to fail. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message