From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 21 17:51:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 622051065672; Wed, 21 Oct 2009 17:51:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3243E8FC13; Wed, 21 Oct 2009 17:51:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AE2B146B06; Wed, 21 Oct 2009 13:51:15 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 85E598A021; Wed, 21 Oct 2009 13:51:14 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 21 Oct 2009 13:40:39 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910211340.39872.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 21 Oct 2009 13:51:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Alexander Best , Robert Watson , Nate Eldredge Subject: Re: mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED 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: Wed, 21 Oct 2009 17:51:16 -0000 On Wednesday 21 October 2009 11:30:51 am Alexander Best wrote: > Robert Watson schrieb am 2009-10-21: > > > On Wed, 21 Oct 2009, Alexander Best wrote: > > > >this code serves only one purpose: to trigger a segfault. i don't > > >use the code for any other purpose. i was under the impression that > > >mmap() should either succeed or fail (tertium non datur). mmap's > > >manual doesn't say anything about mmap() causing segfaults. > > > Have you tried ktracing the application? I think you'll find that > > mmap(2) system call succeeded fine, and that the segfault comes from > > attempting to execute the address in libc on return to userspace, as > > a result of libc not being at that address anymore (since you > > removed its mapping). You can use procstat -v to inspect address > > space use by processes, but as a general rule you don't want to pass > > anything other than an address of 0x0 to mmap(2) unless you're very > > carefully managing the address space of the process. Many userspace > > libraries are involved in using that address space, but especially > > the runtime linker which begins execution in userspace when a binary > > is started. > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > you're right. this kdump shows that the segfault isn't being caused by the > mmap() call: > > 88343 mmap_test CALL > mmap(0x1000,0x80047000,PROT_NONE,MAP_FIXED|MAP_ANON,0xffffffff,0,0) > 88343 mmap_test RET mmap 4096/0x1000 > 88343 mmap_test PSIG SIGSEGV SIG_DFL > 88343 mmap_test NAMI "mmap_test.core" > > thanks for clearing things up. > > however i stil think mentioning this situation in the mmap(2) manual (maybe in > section MAP_FIXED) would be a good idea. I'm not sure it is useful to attempt to enumerate all the possible ways one can shoot one's own foot using mmap(2) in the manual page. The list would be quite long and would require a large amount of imagination. In effect, you are asking for a manual page to document all the possible bugs one could have and manual pages in general do not do that. -- John Baldwin