GNU bug report logs -
#9273
23.3; malloc initialization should (sometimes) happen at runtime
Previous Next
Reported by: Ken Brown <kbrown <at> cornell.edu>
Date: Tue, 9 Aug 2011 20:12:02 UTC
Severity: normal
Found in version 23.3
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
Full log
Message #47 received at 9273 <at> debbugs.gnu.org (full text, mbox):
On 8/13/2011 4:05 AM, Eli Zaretskii wrote:
>> Date: Fri, 12 Aug 2011 16:24:20 -0400
>> From: Ken Brown<kbrown <at> cornell.edu>
>> CC: "9273 <at> debbugs.gnu.org"<9273 <at> 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 = 4294838425
>
> I'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
This bug report was last modified 14 years and 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.