From owner-freebsd-hackers@FreeBSD.ORG Mon May 10 19:09:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3E3E1065678; Mon, 10 May 2010 19:09:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF878FC0A; Mon, 10 May 2010 19:09:42 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o4AJ9c1N001253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 May 2010 22:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o4AJ9cI8013072; Mon, 10 May 2010 22:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o4AJ9cnK013071; Mon, 10 May 2010 22:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 May 2010 22:09:38 +0300 From: Kostik Belousov To: Lev Serebryakov Message-ID: <20100510190938.GR83316@deviant.kiev.zoral.com.ua> References: <1127023465.20100510115708@serebryakov.spb.ru> <20100510145817.GO83316@deviant.kiev.zoral.com.ua> <1638216268.20100510214521@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FWibJpkbnkY6rrXF" Content-Disposition: inline In-Reply-To: <1638216268.20100510214521@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: How to get stack bounds of current process? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 19:09:42 -0000 --FWibJpkbnkY6rrXF Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 09:45:21PM +0400, Lev Serebryakov wrote: > Hello, Kostik. > You wrote 10 =CD=C1=D1 2010 =C7., 18:58:17: >=20 >=20 > >> I'm proting some application from Linux, which discover its stack > >> bounds by reading and pasing "/proc/self/maps". FreeBSD have > >> "/prov/curproc/map", but I can not find how to determine which record > >> is for stack (I've looked into implementation of proc_fs, but it > >> doesn't contain any specail processing for process stack). > >>=20 > >> How could I determine stack bounds of current process on FreeBSD > >> 7/8/9? > > I think the right question is why the program needs the information at = all. >=20 > > Really, the system has no data to answer your question. Which stack are > > you asking for ? The stack of main thread, set up by kernel, is very > > different from the stack established by the threading library for > > newly created thread. What should happen for signal altstacks ? > > Also, the threading library clips the main thread stack to match its > > size with default stack size (I do think this is unsafe and wrong). > It is port of new openjdk7 build. It adds function with > this comment in Linux-specific code (BSD port is based on Linux one): >=20 > // Linux uses a growable mapping for the stack, and if the mapping for > // the stack guard pages is not removed when we detach a thread the > // stack cannot grow beyond the pages where the stack guard was > // mapped. If at some point later in the process the stack expands to > // that point, the Bsd kernel cannot expand the stack any further > // because the guard pages are in the way, and a segfault occurs. > // > // However, it's essential not to split the stack region by unmapping > // a region (leaving a hole) that's already part of the stack mapping, > // so if the stack mapping has already grown beyond the guard pages at > // the time we create them, we have to truncate the stack mapping. > // So, we need to know the extent of the stack mapping when > // create_stack_guard_pages() is called. >=20 > // Find the bounds of the stack mapping. Return true for success. > // > // We only need this for stacks that are growable: at the time of > // writing thread stacks don't use growable mappings (i.e. those > // creeated with MAP_GROWSDOWN), and aren't marked "[stack]", so this > // only applies to the main thread. >=20 > // If the (growable) stack mapping already extends beyond the point > // where we're going to put our guard pages, truncate the mapping at > // that point by munmap()ping it. This ensures that when we later > // munmap() the guard pages we don't leave a hole in the stack > // mapping. >=20 > Solaris code simple map/unmap needed pages, and Linux port > checks stack region and applies special processing for growable stack > area... >=20 > I'm not sure, should BSD port behaves as Linux or as Solaris one. I still do not understand what the program does and why. Text you posted assumes reader understands what the code does and what goals are achieved there. I did mentioned that the threading library puts unmapped region to clip the main thread stack, is this the issue the author of comment worried ? And why this makes him worry ? --FWibJpkbnkY6rrXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvoWfEACgkQC3+MBN1Mb4hSpACfXxgsW2x+uvpyPl5e8mRfifk1 aaIAoKWhNKEymJixaVWvnY3s5kEwVH4E =8LUr -----END PGP SIGNATURE----- --FWibJpkbnkY6rrXF--