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

[Alexander Best]

Nate Eldredge schrieb am 2009-10-21:
> On Wed, 21 Oct 2009, Alexander Best wrote:

> >hi there,

> This is on a 32-bit platform I take it?

yes.

> >just a little mmap(2) related question. running the following code
> >causes a
> >segfault:

> >mmap( (void*)0x1000, 0x80047000, PROT_NONE, MAP_ANON|MAP_FIXED, -1,
> >0 );

> I don't doubt it.  You mapped over a big chunk of your address space
> with memory that's inaccessible (PROT_NONE).  This probably includes
> your program's code.  So when the mmap call returns from the kernel
> and tries to execute the next instruction of your program, it finds
> that the instruction pointer is pointing to inaccessible memory.
> Result: segfault. This is quite normal.

> What are you actually trying to accomplish with this?

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.

from your description of the problem i don't think there's a quick fix to it.
so it might be a good idea to add this case to the mmap(2) bug section.

> >while the following doesn't:

> >mmap( (void*)0x1000, 0xffffffff, PROT_NONE, MAP_ANON|MAP_FIXED, -1,
> >0 );

> Did you check whether the mmap actually succeeded?  I bet it didn't.
>  You have a length that isn't a multiple of the page size and wraps
> around 32 bits.  I bet you got an EINVAL, and the mmap call didn't
> actually do anything.

> >is this a known problem? seems reproducible on all branches.

> Not a problem at all, I suspect.

> --

indeed the mmap() call fails with EINVAL but it doesn't segfault. to make this
clear: i don't expect either one of the  mmap() calls to succeed.

> Nate Eldredge
> nate at thatsmathematics.com