Re: CreateFileMapping & MapViewOfFile

On Tue, 19 Jul 2005 09:20:11 -0700, "Derek L"
<DerekL@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>Hi Everyone,
>
>I has been many moons since I have been a hardcore Win32 developer, but I am
>getting back into it. I wrote a shared memory library for use with porting
>POSIX Unix applications to Win32. For the most part it works great. This is
>what we are doing to create shared memory in this case:
>
>handle = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0,
>len, mname);
>
>ptr = MapViewOfFile(handle, FILE_MAP_WRITE, 0, 0, 0);
>
>This is pseudo code, we actually check all the return values and such, not
>to mention the cover routines for shm_open and mmap contain a heck of a lot
>more.
>
>To get rid of the object, we do:
>
>UnmapViewOfFile(ptr);
>CloseHandle(handle);
>
>One of my co-workers noticed if the same name is used on the next call to
>CreateFileMapping(), then a crash will occur when referencing the memory
>object. If he changes then name, like appending a running counter to it, the
>problem disappears. The mapping of the same name is almost immediately after
>the unmap.
>
>So my questions are:
>
>1. has anyone else encountered this?
>
>2. is this a result of the OS not committing all the pages associated with
>this memory object already, and thus still having pages cached associated
>with this name?
>
>3. should we be calling FlushViewOfFile(), even though INVALID_HANDLE_VALUE
>was passed to CreateFileMapping()?

It looks to me like the shared memory is still in use by another
process, so a handle to the previously-allocated memory is being
returned by CreateFileMapping. If you assume that success (a valid
handle) means new memory has been allocated at the specified size,
this will cause exceptions (when the new size is larger than the old
and you access memory past the old allocation size).

When reopening an existing mapping and assuming it is new, other
conditions can cause exceptions as well, depending on the contents and
usage of the shared memory.

Be sure to check GetLastError() for ERROR_ALREADY_EXISTS *when
CreateFileMapping succeeds*. From MSDN:

Return Values

If the function succeeds, the return value is a handle to the file
mapping object. If the object existed before the function call, the
function returns a handle to the existing object (with its current
size, not the specified size) and GetLastError returns
ERROR_ALREADY_EXISTS.

If the function fails, the return value is NULL. To get extended
error information, call GetLastError.

There are other caveats when running on Terminal Server or "quick user
switching" systems; carefully read the current documentation for
CreateFileMapping.

--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.
.

Relevant Pages

  • [HPADM] RE: SHMMAX modification
    ... The problem is that you are using a 32bit version of Oracle ... will allow access to as much as 1750 megs of shared memory. ... the kernel maintains a map relating the virtual ...
    (HP-UX-Admin)
  • Re: CreateFileMapping & MapViewOfFile
    ... I wrote a shared memory library for use with porting ... The mapping of the same name is almost immediately after ... >>was passed to CreateFileMapping()? ...
    (microsoft.public.win32.programmer.kernel)
  • Re: OpenOffice does not start when Firefox open
    ... openings and closings of OO so I don't think it's a memory leak) ... you're left with this small sliver dividing up the remaining space. ... able to allocate a total amount of shared memory that is more than the ...
    (comp.os.os2.apps)
  • Re: Windows XP Shared memory woes
    ... What is shared memory? ... One of them is 3 gig in size. ... Using process explorer, and several of my own breadcrumbs, I find that I ...
    (microsoft.public.dotnet.framework.performance)
  • Re: [RFC v11][PATCH 05/13] Dump memory address space
    ... in one or more chunk: each chunk begins with a header that specifies ... should not change in the interim anyways, the locks protects us from, e.g. ... Even scanning over a large amount of memory, you aren't going to see a performance difference for accessing pgarr from an argument vs off of field in ctx which is going to be cache-hot. ... It is strictly necessary when it comes to handling shared memory. ...
    (Linux-Kernel)