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: <4E414054.6040206@cornell.edu>
Date: Tue, 09 Aug 2011 10:12:36 -0400
From: Ken Brown <kbrown AT cornell DOT 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 AT cygwin DOT com
Subject: Re: emacs and large-address awareness under recent snapshots
References: <20110807200222 DOT GK11601 AT calimero DOT vinschen DOT de> <4E3F13D8 DOT 7090608 AT cornell DOT edu> <4E3FE323 DOT 9020201 AT cornell DOT edu> <20110808155048 DOT GA28218 AT calimero DOT vinschen DOT de> <4E40093D DOT 10107 AT cornell DOT edu> <20110808162556 DOT GM11601 AT calimero DOT vinschen DOT de> <87sjpbhij7 DOT fsf AT Rainer DOT invalid> <4E404424 DOT 9000600 AT cornell DOT edu> <4E40526C DOT 9080605 AT cornell DOT edu> <4E406C21 DOT 7010007 AT cs DOT umass DOT edu> <20110809082652 DOT GA9492 AT calimero DOT vinschen DOT de> <4E4117AF DOT 3030305 AT cornell DOT edu>
In-Reply-To: <4E4117AF.3030305@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: <cygwin.cygwin.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 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.

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