Re: mmap
Re: mmap
- Subject: Re: mmap
- From: Umesh Vaishampayan <email@hidden>
- Date: Fri, 12 Jul 2002 19:47:38 -0700
On Tuesday, July 9, 2002, at 04:10 PM, Louis Demers wrote:
At 12:27 -0400 2002.07.09, Jim Magee wrote:
On Tuesday, July 9, 2002, at 12:32 AM, Louis Demers wrote:
trying to port inn news server 2.3.3 to osx and the standard
distribution seems to have problems with a mmap call. A static data
is mmap to a file and then porperly written (I dumped all 130180
bytes to a file and it's ok) but when unmapped, the file reverts to
all zeros. I checked and the file descriptor is opened with O_RDWR,
the mmap is done with PROT_WRITE|PROT_READ.
Did you set the MAP_SHARED flag?
GROUPheader = mmap(0, 131080, flag, MAP_SHARED, GROUPfd, 0)
and the file descriptor GROUPfd was opened O_RDWR | O_CREAT.
How large was the file when you mapped it,
Initially the file doesn't exist sot it is created with 0 bytes.
and how much of it did you map?
I imagine that the call to mmap mapped all 131080 and extended the
file.
mmap() does not extend a file. You have to use truncate()/ftruncate()
or write()/pwrite() to extend the file.
See
<
http://www.opengroup.org/onlinepubs/007904975/toc.htm>
For SUSV3 spec for mmap()
"If the size of the mapped file changes after the call to mmap() as a
result of some other operation on the mapped file, the effect of
references to portions of the mapped region that correspond to added or
removed portions of the file is unspecified."
"The system shall always zero-fill any partial page at the end of an
object. Further, the system shall never write out any modified portions
of the last page of an object which are beyond its end."
"[ENXIO]
Addresses in the range [off,off+len) are invalid for the object
specified by fildes."
So your mmap(0, 131080, flag, MAP_SHARED, GROUPfd, 0), should have
failed for the 0 sized file.
However it also allows the implementation to not treat the request as
"invalid" provided that:
"The mmap() function can be used to map a region of memory that is
larger than the current size of the object. Memory access within the
mapping but beyond the current end of the underlying objects may result
in SIGBUS signals being sent to the process. The reason for this is
that the size of the object can be manipulated by other processes and
can change at any moment. The implementation should tell the
application that a memory reference is outside the object where this
can be detected; otherwise, written data may be lost and read data may
not reflect actual data in the object."
So your store to memory should have generated a SIGBUS.... [Please file
a bug].
If you read further:
"Note that references beyond the end of the object do not extend the
object as the new end cannot be determined precisely by most virtual
memory hardware. Instead, the size can be directly manipulated by
ftruncate()."
Hope this helps,
--Umesh
--
Umesh Vaishampayan Apple Computer, Inc.
Mac OS X Kernel Ph: (408) 974 0229
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.
| References: | |
| | >Re: mmap (From: Louis Demers <email@hidden>) |