| delorie.com/archives/browse.cgi | search |
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 a theory. Emacs is estimating its heap size as being approximately result+size (i.e., it is assuming its heap is in relatively low memory). Given the value of result, now in the upper half of memory, it tries to compute a heap size (by doubling newsize repeatedly), and thus will double until newsize goes to 0. If this theory is correct, a base needs to be subtracted. If that is happening in the BLOCK macro, and if Ken is right that heapbase is a small value, then that could well be the problem: heapbase needs to be "reset" to 0x80000000 ... Regards -- Eliot Moss -- 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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |