X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_NEUTRAL X-Spam-Check-By: sourceware.org Message-ID: <4E3FE323.9020201@cornell.edu> Date: Mon, 08 Aug 2011 09:22:43 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: emacs and large-address awareness under recent snapshots References: <4E3C79E0 DOT 3030506 AT cornell DOT edu> <20110807113354 DOT GG11601 AT calimero DOT vinschen DOT de> <20110807115056 DOT GI11601 AT calimero DOT vinschen DOT de> <4E3EA497 DOT 7040402 AT cornell DOT edu> <4E3EBAEF DOT 1030004 AT cornell DOT edu> <20110807200222 DOT GK11601 AT calimero DOT vinschen DOT de> <4E3F13D8 DOT 7090608 AT cornell DOT edu> In-Reply-To: <4E3F13D8.7090608@cornell.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 8/7/2011 6:38 PM, Ken Brown wrote: > I've built cygwin1.dll from the latest CVS and confirmed that the > problem is fixed. Unfortunately, I've just discovered a second problem, > also starting with the 2011-07-21 snapshot, that only shows up when I > try to start emacs under X (with emacs large address aware). What > happens here is that emacs keeps using more and more CPU (as shown by > Windows Task Manager), but the emacs window never opens. To reproduce, > install emacs-X11 and then do the following: > > 1. $ peflags --bigaddr=1 /usr/bin/emacs-X11.exe > > 2. Start the X server. (I use the Start Menu shortcut.) > > 3. Start emacs from an xterm window: > > $ emacs -Q& > > As a slight variation on this, you can instead start emacs with the -nw > option: > > $ emacs -nw -Q > > This tells emacs to use the xterm window for display rather than opening > its own window. The result this time is that you can see the emacs > display, but emacs is unresponsive while the CPU usage increases as before. I attached gdb to the running process and got some more information. It turns out that this has nothing to do with X. It's just that starting emacs under X causes emacs to try to allocate memory, and this makes the problem show up very quickly. It looks to me like emacs gets stuck in morecore_nolock() and/or _malloc_internal_nolock(), which are defined in src/gmalloc.c. Apparently, emacs has a peculiar way of managing memory on Cygwin, and this chokes on the changes to the heap start address as of 2011-07-21. I don't know enough programming to fix this. If anyone wants to try, the relevant source files to look at are gmalloc.c, sheap.c, and unexcw.c. The second and third are compiled only in the Cygwin build, and the first also has some Cygwin-specific stuff. Maybe I should take this to the emacs-devel list at some point, but I'll wait a while to see if someone on this list can help. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple