X-Spam-Check-By: sourceware.org Date: Sat, 12 Aug 2006 18:53:00 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Cc: Eli Zaretskii , emacs-pretest-bug AT gnu DOT org, emacs_user AT hotmail DOT com Subject: Re: reproducible cygwin memory problems Message-ID: <20060812165300.GB19272@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com, emacs-pretest-bug AT gnu DOT org Mail-Followup-To: cygwin AT cygwin DOT com, Eli Zaretskii , emacs-pretest-bug AT gnu DOT org, emacs_user AT hotmail DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Aug 12 17:52, Eli Zaretskii wrote: > It's possible that I'm wrong, of course. Let me state the facts and > observations that led me to my conclusion: > > . The OP reported that the problem happens only with image files. > When he edits text files, the Emacs memory footprint stays at a > reasonable value. > > . After killing the image buffer, the OP invoked the Lisp function > clear-image-cache, which is supposed to release any memory used by > Emacs for storing images. There's no other Lisp memory that I can > see in the sources that is used for images, and that could be left > unreleased. To be sure, I'd like to ask emacs_user AT hotmail DOT com, > who is the OP, to invoke "M-x garbage-collect RET" after > clear-image-cache, and see if that changes anything. > > . The OP traced the Emacs code in clear-image-cache, and saw that > the function in the image libraries that frees the image is indeed > called. > > . Other Emacs builds, including the native Windows build and a > GNU/Linux build, do not exhibit this behavior. > > Given these observations, and the fact that the Cygwin build of Emacs > runs almost the same C and Lisp code as the GNU/Linux build, what > other factors can be involved here? Cygwin uses the Doug Lea version of malloc/free. The latest Cygwin versions uses the DEFAULT_MMAP_THRESHOLD of 256K, so mmap/munmap are used for mappings > 256K. I assume that's the case here, since we're talking about images. Otherwise, for mallocs < 256K, Cygwin is using sbrk and sbrk'ed memory is never returned to the OS. 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 :) 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/