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:
do
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) >
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.
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
