mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED

[Alexander Best]

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.

cheers.
alex