|
From: | Ken Brown |
Subject: | bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime |
Date: | Sat, 13 Aug 2011 09:48:52 -0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 |
On 8/13/2011 4:05 AM, Eli Zaretskii wrote:
Date: Fri, 12 Aug 2011 16:24:20 -0400 From: Ken Brown<kbrown@cornell.edu> CC: "9273@debbugs.gnu.org"<9273@debbugs.gnu.org> Program received signal SIGSEGV, Segmentation fault. 0x006368f5 in _realloc_internal_nolock (ptr=0x897040, size=28) at gmalloc.c:1394 1394 type = _heapinfo[block].busy.type; (gdb) p block $1 = 4294838425I'm confused: since you patched unexecw.c to set __malloc_initialized to zero, the dumped Emacs should have called malloc_initialize_1, which should have allocated a new copy of _heapinfo, that was supposed to be consistent with the current heap. Why isn't that working? why `block' still gets a value that is relative to the "old" _heapinfo?
_heapinfo is indeed consistent with the current heap. But the pointer that was passed to realloc points into the old heap. So applying BLOCK to that pointer yields an absurd result. I can easily catch such cases by testing for ptr < _heapbase, as in my patch to _free_internal_nolock, but I have to figure out the best way to handle them once I've caught them. I have work in progress that tries to keep track of both heaps, but I haven't got it working yet.
An alternative would be to have realloc return NULL (or some other special value) in these cases, but then I would have to find all possible callers of realloc (with pointers to the old heap) and make sure they know how to deal with that return value. I'm guessing my first approach is safer and easier to implement.
Ken
[Prev in Thread] | Current Thread | [Next in Thread] |