While this also passes on mine - mmap has been performing strangely for me also (since around November snapshots).
SPECIFICALLY: After the "allocate downwards" change was done, mmap calls started returning ENOMEM ("Cannot allocate memory") where they worked before just fine. I specifically noticed in only in one threaded application of mine but was unable to create a test case that could duplicate it - so I haven't really posted up the issue either. I will also say this, I only get ENOMEM if mmap() tries to map a file LESS than the system page size. That is what I can duplicate everytime. Once it rises above the pagesize, then mmap() has no issues. The actual manifestation of failure is MAP_FAILED returned from mmap(). While his test case may have passed for the both of us, there is definitely something funky going on with mmap() since the allocate downwards change was OR'd into the underlying VirtualAlloc() call. -cl On Fri, Jan 05, 2007 at 10:57:52AM +0100, Corinna Vinschen wrote: > On Jan 4 17:17, Brian Ford wrote: > > $ uname -a > > CYGWIN_NT-5.1 PC1163-8460-XP 1.7.0(0.161/4/2) 2007-01-04 15:51 i686 > > unknown unknown Cygwin > > > > $ ./mmaptest.exe > > CloseHandle(fh_disk_file.get_handle ()) 0x738 failed void* mmap64(void*, > > size_t, int, int, int, _off64_t):1275, Win32 error 6 > > mmap: Cannot allocate memory > > > > STC attached. Thanks. > > Hmm, STCs are nice, but this STC works fine for me, reproducibly: > > $ ./mmaptest > test passed > > Something's missing in the picture... -- 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/