Message-ID: <4E40093D.10107@cornell.edu>
Date: Mon, 08 Aug 2011 12:05:17 -0400
From: Ken Brown <kbrown@cornell.edu>
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@cygwin.com
Subject: Re: emacs and large-address awareness under recent snapshots
References: <4E3C79E0.3030506@cornell.edu> <20110807113354.GG11601@calimero.vinschen.de> <20110807115056.GI11601@calimero.vinschen.de> <4E3EA497.7040402@cornell.edu> <4E3EBAEF.1030004@cornell.edu> <20110807200222.GK11601@calimero.vinschen.de> <4E3F13D8.7090608@cornell.edu> <4E3FE323.9020201@cornell.edu> <20110808155048.GA28218@calimero.vinschen.de>
In-Reply-To: <20110808155048.GA28218@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 8/8/2011 11:50 AM, Corinna Vinschen wrote:
> On Aug  8 09:22, Ken Brown wrote:
>> 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.
>
> I had a look into the sources you're mentioning above, but I don't see
> anything suspicious, apart from the fact that emacs uses some static
> buffer of 12 Megs as heap on Cygwin... sometimes.  At least that's what
> sheap.c is about, afaics.

I'll build a debug version and try stepping through the functions I 
mentioned.  Maybe I can figure out what's happening.  I suspect that it 
does have something to do with the static heap.

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