[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reproducible cygwin memory problems

From: Reini Urban
Subject: Re: reproducible cygwin memory problems
Date: Sun, 13 Aug 2006 11:23:16 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv: Gecko/20060729 SeaMonkey/1.0.4

Corinna Vinschen schrieb:
Ok, back to mmap/munmap.  Private anonymous mappings are implemented in
Cygwin by calling VirtualAlloc/VirtualFree.  However, due to
restrictions in the Win32 API, VirtualFree is only called by munmap, as
soon as *all* pages within a single mmap'ed area are free'ed by this or
preceding calls to munmap.

In other words, the mmap'ed memory will not be returned to the OS, if
not the complete mmap'ed area is munmap'ed.  Therefore I assume that the
implementation in Lisp keeps bits of memory around which are not
munmap'ed for some internal reason.

Of course it's also possible that there's a bug in Cygwin related to the
way mmap/munmap is called.  But I have so far no evidence for that and
simple mmap/munmap tests show that VirtualFree is called as soon as all
pages in a mmap'ed area have been munmap'ed.  If somebody thinks there's
a bug in this implementation, please send a simple, self-contained
testcase in pure C source code, which allows to reproduce the problem.
Of course, patches are welcome, too :)

And there's the known mmap() under cygwin limitation, esp. harmful to clisp, that mmap() can only be properly aligned to a base address modulo 64k (windows "allocation granularity"), and not the usual pagesize, if it's 4k or 8k. windows pagesize is still 4k though.


This has nothing directly to do with the possible xemacs munmap() problem, but maybe there's a logic flaw somewhere.
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]