1.7.0 CVS mmap failure
Wed Jan 17 10:40:00 GMT 2007
On Jan 16 17:28, Brian Ford wrote:
> On Wed, 10 Jan 2007, Brian Ford wrote:
> > On Wed, 10 Jan 2007, Corinna Vinschen wrote:
> > > I implemented the above mentioned technique, which isn't much code
> > > anyway. It reserves a memory lot big enough to fit in the whole
> > > mapping, memorizes the address, free's the memory again and then uses
> > > the new address in the subsequent real mappings.
> > >
> > > This should work (knock on wood) on all systems now. My testcases still
> > > work on my 512 MB machine, so I'd appreciate if you could give the latest
> > > snapshot a try on /3GB enabled machines.
> > Yes, this fixes my STC and the application from which it was derived.
> > Thanks.
> But, it breaks another application that supplies a suggested mmap address
> (not MAP_FIXED) that is not available. The VirtualAlloc needs a retry in
> that case.
Ouch, right. I'll fix that.
> Maybe the retries can then be removed from the other two
They might be unnecessary now, but OTOH they don't hurt. I'll add
a comment but keep the code for now.
> PS: In an strace of this, I see three fstat64s called from within a
> single mmap64. Do you know where they all are, and if two should be
> optimized away?
There's only one such call in list::set.
Your observation is strange. The first mapping, which really maps the
file, calls fstat. The second (valid remainder) and third (sigbus area)
mapping are anonymous mappings, which don't call fstat. In my tests,
fstat64 is called only once for a file mapping. STC?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin