emacs and large-address awareness under recent snapshots
Tue Aug 9 11:19:00 GMT 2011
On 8/9/2011 4:26 AM, Corinna Vinschen wrote:
> On Aug 8 19:07, Eliot Moss wrote:
>> On 8/8/2011 5:17 PM, Ken Brown wrote:
>>> newsize *= 2;
>>> while ((__malloc_size_t) BLOCK ((char *) result + size)> newsize);
>>> My guess now is that there was some invalid pointer arithmetic somewhere that led to this, but I
>>> don't have time at the moment to look for it. I'll do it later (or tomorrow) if no one beats me to it.
>> Possibly, Ken. I also wonder about signed vs unsigned calculations
>> and such. We are looking at the higher end of the address space,
>> which means negative addresses when considered as signed numbers.
>> I'm not sure what the above is doing, but if it is trying to
>> double its understanding of the heap size, based on using the
>> current end of the heap (result?) as a measure of size, then
>> if the heap is at 0x80000000, doubling that gives 0 in a 32-bit
>> address space ...
> The question is, how could newsize ever become>= 0x80000000?
> Ken, what are the values of result and size? And what value has
> heapsize? Consider that the statement before the loop is
> newsize = heapsize;
(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) >
(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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin