Mail Archives: cygwin/2007/01/05/14:03:06
On 05 January 2007 18:47, Dave Korn wrote:
> On 05 January 2007 18:42, Brian Ford wrote:
>
>> 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.
>
>
> Normally in windows you have the PEB and various TEBs living in that
> region. I have no idea how this behaves on x64 or with /3gb, but it would
> seem that it is still reserved.
And indeed (hit send too quickly), this is a violation of the otherwise
absolute rule that everything is done in 64k pages. I think it's a real
problem that windows would allocate the low-end partial part of the 64k page
containing the fs segment.
Maybe cygwin just wants to allocate that range on startup and then discard
it, leaving it allocated, so that mmap doesn't ever run the risk of getting
handed a partial page that it can't allocate/map the rest of.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -