Message-ID: <4E4142F7.8020708@cornell.edu>
Date: Tue, 09 Aug 2011 10:23:51 -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: <20110807200222.GK11601@calimero.vinschen.de> <4E3F13D8.7090608@cornell.edu> <4E3FE323.9020201@cornell.edu> <20110808155048.GA28218@calimero.vinschen.de> <4E40093D.10107@cornell.edu> <20110808162556.GM11601@calimero.vinschen.de> <87sjpbhij7.fsf@Rainer.invalid> <4E404424.9000600@cornell.edu> <4E40526C.9080605@cornell.edu> <4E406C21.7010007@cs.umass.edu> <20110809082652.GA9492@calimero.vinschen.de> <4E4117AF.3030305@cornell.edu> <4E414054.6040206@cornell.edu>
In-Reply-To: <4E414054.6040206@cornell.edu>
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/9/2011 10:12 AM, Ken Brown wrote:
> On 8/9/2011 7:19 AM, Ken Brown wrote:
>> (gdb) thread 1
>> [Switching to thread 1 (Thread 19828.0x447c)]
>> #0  0x00622ee0 in morecore_nolock (size=1052672) at gmalloc.c:703
>> 703           while ((__malloc_size_t) BLOCK ((char *) result + size)>
>> newsize);
>> (gdb) p /x size
>> $1 = 0x101000
>> (gdb) p /x heapsize
>> $2 = 0x80000
>> (gdb) p result
>> $3 = (void *) 0x807d0000
>> (gdb) p newsize
>> $4 = 0
>> (gdb) p _heapbase
>> $5 = 0x816000 "\202"
>> (gdb) p _heapinfo
>> $6 = (malloc_info *) 0x80060000
>>
>> Is _heapbase the problem?  This is initialized to _heapinfo at the first
>> call of malloc and is never changed.  _heapinfo presumably points into
>> the static heap at that point.  (_heapinfo is later changed as a result
>> of realloc.)  This low value of _heapbase is used in the BLOCK macro.
>
> Here's what I think is happening.  When temacs.exe is running during the
> build process (see my explanation of this earlier in the thread),
> malloc_init is called and _heapbase is set.  At this point, temacs is
> using its own static buffer as the heap, and _heapbase gets the value
> 0x816000.  This gets dumped as initialized data into emacs.exe, as does
> the value __malloc_initialized = 1.  Now when emacs.exe is run, it sees
> that malloc has already been initialized, so _heapbase retains its
> value, which is no longer appropriate.  All code relying on the BLOCK
> macro is now invalid.
>
> AFAICS, this has always been wrong.  But the error didn't have dramatic
> consequences until the heap was put into high memory.
>
> I'm not sure what's the best way to fix this (assuming my analysis is
> right).  Would it be enough to set __malloc_initialized to 0 before
> dumping?  That would force emacs to reinitialize and get the correct
> value of _heapbase.

No, that's too simple-minded.  I just tried it, and emacs aborted.  This 
seems like a mess.

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