| 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 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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |