This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 1.7.0 CVS mmap failure
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
> locations?
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/