X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Date:	Mon, 8 Aug 2011 17:40:12 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: emacs and large-address awareness under recent snapshots
Message-ID:	<20110808154012.GL11601@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
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>
MIME-Version:	1.0
In-Reply-To:	<4E3F13D8.7090608@cornell.edu>
User-Agent:	Mutt/1.5.21 (2010-09-15)
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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  7 18:38, Ken Brown wrote:
> On 8/7/2011 4:02 PM, Corinna Vinschen wrote:
> >What I did now is to change Cygwin to return always RLIM_INFINITY in
> >a call to getrlimit(RLIMIT_AS).  This seems to be more correct anyway,
> >given the definition in SUSv4(*):
> >
> >   "If a call to getrlimit() returns RLIM_INFINITY for a resource, it
> >    means the implementation shall not enforce limits on that resource."
> >
> >That's exactly our situation.  There's no enforced limit on the VM,
> >other than the size of the VM itself.  Now emacs is happy.
> 
> 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 can reproduce this, but from the strace I can't figure out what emacs
is doing.  There are a lot of threads running in parallel.  GDB isn't a
big help either, given that I have no debug symbols for emacs.

I'm still looking into this, but I need your help.  If you have a hunch
where the problem occurs in emacs, add some debug output to the code
or try to set a breakpoint in the affected function.  Everything helps.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

- Raw text -