This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.0 CVS mmap failure

On Jan  5 11:52, Brian Ford wrote:
> Here is an interesting strace comparison:
> Non-/3GB:
>  4978   26688 [main] mmaptest 2284 MapViewNT: 7FFA0000 =
> NtMapViewOfSection (h:6EC, addr:0, len:28237, off:0, protect:80, type:0)
> [snip]
>     60   27113 [main] mmaptest 2284 MapViewNT: 7FFA7000 =
> NtMapViewOfSection (h:6E8, addr:7FFA7000, len:36864, off:0, protect:80, type:0)
>   126   27239 [main] mmaptest 2284 mmap64: 0x7FFA0000 = mmap()
> /3GB not large address aware:
>   183   22192 [main] mmaptest 2856 MapViewNT: 7FFF0000 =
> NtMapViewOfSection (h:6F0, addr:0, len:28237, off:0, protect:80, type:0)
> [snip]
>    68   22648 [main] mmaptest 2856 MapViewNT: 0 = NtMapViewOfSection
> (h:6EC, addr:7FFF7000, len:36864, off:0, protect:80, type:0)
>    44   22692 [main] mmaptest 2856 seterrno_from_win_error:
> ../../../../cygwin/winsup/cygwin/ windows error 487
>    46   22738 [main] mmaptest 2856 geterrno_from_win_error: windows error
> 487 == errno 22
>    41   22779 [main] mmaptest 2856 __set_errno: void
> seterrno_from_win_error(const char*, int, DWORD):310 val 22
>    79   22858 [main] mmaptest 2856 __set_errno: void* mmap64(void*,
> size_t, int, int, int, _off64_t):1251 val 12
> --- Process 2856, exception C0000008 at 7C90EB74
> 13337   36195 [main] mmaptest 2856 mmap64: 0xFFFFFFFF = mmap()
> /3GB large address aware:
>   191   22246 [main] mmaptest 3420 MapViewNT: AEFA0000 =
> NtMapViewOfSection (h:6EC, addr:0, len:28237, off:0, protect:80, type:0)
> [snip]
>    66   22676 [main] mmaptest 3420 MapViewNT: AEFA7000 =
> NtMapViewOfSection (h:6E8, addr:AEFA7000, len:36864, off:0, protect:80,
> type:0)
>   126   22802 [main] mmaptest 3420 mmap64: 0xAEFA0000 = mmap()
> The second MapViewNT call is filling out the padding to a 64k boundary.
> It appears in the problem case that the system doesn't like the 0x7FFF7000
> address.  Any idea why?

That's not visible in the above strace.  Since the pagesize is supposed
to be == allocation granularity == 64K, but file mappings are aligned
to the next page boundary beyond EOF (sigh), Cygwin tries to accomodate
the expectations of the application by appending an anonymous mapping
to fill the whole mapping up to 64K.  In the failing case this should
still work, since 0x7fff7000 + 0x9000 (36864 dec) == 0x80000000, so the
mapping should fit into the usual 2 Gig address space.  Why Windows
fails to do it, I have no idea.  The error code 487 means invalid
address which might mean "already taken" address, but that's not visible
in the strace.  To figure that out would require to add a bit of
VirtualQuery code to mmap and add appropriate debug output.

Actually this shows a problem in the mmap implementation with respect to
MEM_TOP_DOWN.  I think, what mmap should actually do is to create a
lightweight MAP_RESERVE anonymous mapping of the whole requested mapping
size, then close it again and then reopen it with the address it got
in this first try.  This would probably ensure that the subsequent two
mapping will work.  However, it's not quite clear if that really would
help since the above *should* have worked to the best of my knowledge.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]