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 > n...@thatsmathematics.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
