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 Fri, 5 Jan 2007, Corinna Vinschen wrote:

> 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.

I'm not quite sure exactly what this means, but I stumbled onto it in gdb:

(gdb) info w32 selector
Selector $fs
0x03b: base=0x7fffe000 limit=0x00000fff 32-bit Data (Read/Write, Exp-up)
Priviledge level = 3. Byte granular.

So, it does indeed look taken.

> 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.

I don't know what mmap magic Cygwin uses internally to do this, but can't
you just map the big region, then overmap the disk file without the map,
unmap, remap, remap?

Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

Unsubscribe info:
Problem reports:

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