emacs and large-address awareness under recent snapshots

[Ken Brown]

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