From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 11 20:21:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B587BEDD for ; Tue, 11 Jun 2013 20:21:36 +0000 (UTC) (envelope-from vagner@bsdway.ru) Received: from bsdway.ru (bsdway.ru [62.109.17.46]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6181AB8 for ; Tue, 11 Jun 2013 20:21:35 +0000 (UTC) Received: from localhost ([188.134.95.3]) (authenticated bits=0) by bsdway.ru (8.14.4/8.14.5) with ESMTP id r5BKLR42010823; Wed, 12 Jun 2013 00:21:28 +0400 (MSD) (envelope-from vagner@bsdway.ru) Date: Wed, 12 Jun 2013 00:21:22 +0400 From: Vagner To: Konstantin Belousov , FreeBSD hackers Mail List Subject: Re: Where is stack of program? Message-ID: <20130611202122.GA3348@vagner-wrk.bsdway.ru> Mail-Followup-To: Konstantin Belousov , FreeBSD hackers Mail List References: <20130610164425.GA2966@vagner-wrk.bsdway.ru> <20130611054544.GI3047@kib.kiev.ua> <20130611080538.GA2645@vagner-wrk.bsdway.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20130611080538.GA2645@vagner-wrk.bsdway.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bsdway.ru [62.109.17.46]); Wed, 12 Jun 2013 00:21:28 +0400 (MSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:21:36 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 12:05 Tue 11 Jun , Vagner wrote: > On 08:45 Tue 11 Jun , Konstantin Belousov wrote: > > On Mon, Jun 10, 2013 at 08:44:25PM +0400, Vagner wrote: > > > Hi! > > > I need method of finding in struct vm_map or vm_object segments of > > > memory which is situated in the stack. > > > Can you help me please? > > > > Note that the stack is per-thread. The concept is somewhat machine-specific, > > some architectures utilize two stacks, on some the stack is purely software > > convention. > > > > You did not specified what context your code is to be run, e.g. is > > it kernel or user space ? Assuming it is kernel since you mentioned > > vm_something. The least error prone route is the thread context (frame) > > -> tf_esp on i386 (or tf_rsp on amd64) -> lookup of the map entry in the > > process p_vmspace. > > > > In reality, the stack is often fragmented, since the stack grow code > > does not coalesce the adjacent grow-down map entries. > > I asket the question because in my servers run very large daemons (writed their own). Then daemons get > signal for create coredump, downtime approximately 1h. This is very long for daemons in > production. Often in coredump for debug need only stack and current > frame of code, but in function, which initialise for create dump of > memory haven't this possibility. Linux have /proc/self/coredump_filter > for settings what segments included in core file, but in our FreeBSD I > don't find this:( Help me for find solution please > My solution. I added new option MALLOC_OPTIONS ("S") in environment variable for malloc(3). Also I added new `if' in function pages_map at libc/stdlib. In this `if' I added option MAP_NOCORE (mmap(2)) for segments allocated with MAP_PRIVATE | MAP_ANON. Patch file attached. As a result: I have a corefile with stack and text of program ~ 2Mb (above - 2Gb). Thanks to all -- Respectfully, Stanislav Putrya System administrator FotoStrana.Ru Ltd. ICQ IM: 328585847 Jabber-GoogleTalk: root.vagner mob.phone SPB: +79215788755 mob.phone RND: +79525600664 email: vagner[at]bsdway.ru email: putrya[at]playform.ru email: root.vagner[at]gmail.com site: bsdway.ru site: fotostrana.ru ---------------------------------------- ( ) ASCII ribbon campaign X - against HTML, vCards and / \ - proprietary attachments in e-mail --SUOF0GtieIMvvwua Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="core_only_stack.patch" Index: lib/libc/stdlib/malloc.c =================================================================== --- lib/libc/stdlib/malloc.c (revision 249257) +++ lib/libc/stdlib/malloc.c (working copy) @@ -1155,9 +1155,11 @@ #ifndef MALLOC_PRODUCTION static bool opt_abort = true; static bool opt_junk = true; +static bool opt_stackcore = false; #else static bool opt_abort = false; static bool opt_junk = false; +static bool opt_stackcore = false; #endif #ifdef MALLOC_TCACHE static size_t opt_lg_tcache_nslots = LG_TCACHE_NSLOTS_DEFAULT; @@ -1797,8 +1799,12 @@ * We don't use MAP_FIXED here, because it can cause the *replacement* * of existing mappings, and we only want to create new mappings. */ - ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, + if (opt_stackcore) + ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_NOCORE, -1, 0); + else + ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, + -1, 0); assert(ret != NULL); if (ret == MAP_FAILED) @@ -5623,6 +5629,9 @@ case 'P': opt_stats_print = true; break; + case 'S': + opt_stackcore = true; + break; case 'q': if (opt_lg_qspace_max > LG_QUANTUM) opt_lg_qspace_max--; --SUOF0GtieIMvvwua--