[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9273: 23.3; malloc initialization should (sometimes) happen at runti

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<address@hidden>
CC: "address@hidden"<address@hidden>

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]