#18 win32: mmap segmentation faults with mingw


win32_mmap writes to *user, which is io->fd.sys. However, default_io is const so writing to it causes a segmentation fault. There's no need to keep the file mapping HANDLE around, so this patch just stores it locally then closes it right away.

Also, returning the pointer plus the offset appears to be the wrong behavior. I was getting segfaults until I changed it to return just the pointer, like POSIX mmap.

With these changes applied, zziplib can use mmap when (cross-)compiled with mingw. I believe they should work fine for MSVC but I have not tried them.

1 Attachments


  • Guido U. Draheim

    I am not actually sure that this can be merged without intensive testing on different windows implementations. The Microsoft documentation is not quite clear whether a file mapping object may be closed asserting that the view is left intact. There is only a note in the documentation on UnmapViewOfFile

    "Although an application may close the file handle used to create a file mapping object, the system holds the corresponding file open until the last view of the file is unmapped. Files for which the last view has not yet been unmapped are held open with no sharing restrictions."

    Note that this talks about the "file handle", i.e. the argument to CreateFileMapping instead of the return value being a "file mapping object".

    Talking about the initial observation:

    Your patch seems to try to get rid of writing to the *user variable. In the mmapped example I haven't been using fd.sys and it seems better to stay away from writing to the plugin_io as it is indeed intended to be initialized once for all zip files to be opened. So actually, the fd.sys usage should be wiped out - and it seems that the mmmap'ing is only used during parsing of the zip file structure were munmap is called in the same function. So the user variable can be put on the runtime stack.

    We'll, may be...

  • Gregory Smith

    Gregory Smith - 2013-11-07

    The documentation for CreateFileMapping led me to believe the approach in the patch is OK:

    Mapped views of a file mapping object maintain internal references to the
    object, and a file mapping object does not close until all references to it
    are released. Therefore, to fully close a file mapping object, an
    application must unmap all mapped views of the file mapping object by
    calling UnmapViewOfFile and close the file mapping object handle by calling
    CloseHandle. These functions can be called in any order.

    In particular, according to the last sentence, it should be OK to call CloseHandle before UnmapViewOfFile.

    If you want to fix the write to fd.sys another way, that's great too.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks