From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/397 Path: news.gmane.org!not-for-mail From: Vasiliy Kulikov Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc and linux memory layout Date: Thu, 11 Aug 2011 11:43:05 +0400 Message-ID: <20110811074305.GA4276@albatros> References: <20110810195658.GC132@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1313048608 23881 80.91.229.12 (11 Aug 2011 07:43:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 11 Aug 2011 07:43:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-398-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 11 09:43:24 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QrPvG-00013J-2Z for gllmg-musl@lo.gmane.org; Thu, 11 Aug 2011 09:43:22 +0200 Original-Received: (qmail 14291 invoked by uid 550); 11 Aug 2011 07:43:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14281 invoked from network); 11 Aug 2011 07:43:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5Y+CdpIo6qxJQSmYnyx4NDKhkcWyJBLeVN+3ppXJO+Q=; b=jj5N4nZWHXK3WPz5Qqo1XEY8P9CLioMd8BUAT7ss9FH/nZ2acPIDcRN3kingQltfF9 RWiEILZWt51M3KgAVWgAOQff9iSuMXJ9TtzQIxGwWVA86k2eY2VuKLhbOXqmzBfokqel 672/JUV5gSporCD1Yqrmv6Xyf//uoT992vJYM= Original-Sender: Vasiliy Kulikov Content-Disposition: inline In-Reply-To: <20110810195658.GC132@brightrain.aerifal.cx> User-Agent: Mutt/1.5.20 (2009-06-14) Xref: news.gmane.org gmane.linux.lib.musl.general:397 Archived-At: On Wed, Aug 10, 2011 at 15:56 -0400, Rich Felker wrote: > Each process has its own 32- or 64-bit virtual address space. > Initially, from bottom to top, it looks something like: > > [low unmappable pages] > [main program text (code) segment] > [main program data segment] > [brk segment (heap)] > [....lots of open virtual address space...] > [mmap zone] > [main thread stack] > [reserved for kernelspace use] > > (Note that there will be small randomized amounts of empty/unused > address space between these regions if ALSR is enabled.)x > > The brk segment starts just above the program's static data and grows > upward into the big open space. Btw, (randomize_va_space): http://www.mjmwired.net/kernel/Documentation/sysctl/kernel.txt > The mmap zone (where mmaps are put by > default) starts just below the stack limit and continues downward as > more mappings are made. Not only this zone. mmap() can return address before main program text if there is enough space there. Other minor (Linux-specific) things: Low unmappable pages region might be absent if the task has CAP_SYS_RAWIO capability. But pages before mmap_min_addr will be mmap'ed only by explicit mmap(addr, ..., MAP_FIXED, ...), no libs will be there. "Reserved for kernelspace use" region might be absent too for 32-bit tasks running on 286-64 system. There could be some specific pages after the stack. On x86-64 it is VDSO and vsyscall pages. -- Vasiliy