Package: emacs;
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.
Message #38 received at 9273 <at> debbugs.gnu.org (full text, mbox):
From: Ken Brown <kbrown <at> cornell.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: "9273 <at> debbugs.gnu.org" <9273 <at> debbugs.gnu.org> Subject: Re: bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime Date: Fri, 12 Aug 2011 16:24:20 -0400
On 8/12/2011 8:18 AM, Ken Brown wrote:
> On 8/12/2011 7:33 AM, Eli Zaretskii wrote:
>>> Date: Fri, 12 Aug 2011 06:10:35 -0400
>>> From: Ken Brown<kbrown <at> cornell.edu>
>>> CC: "9273 <at> debbugs.gnu.org"<9273 <at> debbugs.gnu.org>
>>>
>>> On 8/12/2011 2:54 AM, Eli Zaretskii wrote:
>>>>> Date: Thu, 11 Aug 2011 17:45:41 -0400
>>>>> From: Ken Brown<kbrown <at> cornell.edu>
>>>>> CC: "9273 <at> debbugs.gnu.org"<9273 <at> debbugs.gnu.org>
>>>>>
>>>>> The problem was that realloc got called on memory that had been
>>>>> allocated prior to dumping, and the malloc information that was used
>>>>> then had disappeared.
>>>>
>>>> Can you show the code which called realloc on that memory? I'm
>>>> surprised that Emacs does that, but perhaps I'm missing something.
>>>
>>> Here's the code that I stumbled across (as a result of a SEGV). I
>>> haven't checked to see if there are other examples. From terminal.c:
>>>
>>> /* Deletes the bootstrap terminal device.
>>> Called through delete_terminal_hook. */
>>>
>>> static void
>>> delete_initial_terminal (struct terminal *terminal)
>>> {
>>> if (terminal != initial_terminal)
>>> abort ();
>>>
>>> delete_terminal (terminal);
>>> initial_terminal = NULL;
>>> }
>>
>> delete_terminal doesn't call realloc, it just calls xfree.
>
> Maybe I mis-remembered where the call to realloc is. I'll reproduce it
> later and let you know. (I don't have time at the moment.) But I
> assure you that I did a backtrace showing that realloc was called on
> something related to terminals.
>
>> Do the problems with the Cygwin build go away if the call to
>> delete_terminal is commented out?
>
> No. At the very least, I have to force reinitialization of malloc.
> Otherwise the BLOCK macro yields wrong results that lead to infinite
> looping or crashing. After reinitialization, I have to be able to
> handle calls to free() on memory allocated prior to dumping. Probably
> it's OK to just ignore such calls. If I can also take care of calls to
> realloc too, everything will be OK.
OK, here's a backtrace showing realloc being called on memory in the static heap (at 0x897040). This is after applying the patch appended at the end of this message. (I think it's self-explanatory, but I'll be glad to explain further.)
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/test/src/emacs.exe -Q
[New Thread 4756.0x1144]
warning: cYgFFFFFFFF 611857C0
[New Thread 4756.0xd80]
warning: cYgstd 28ccf5 d 3
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
(gdb) bt
#0 0x006368f5 in _realloc_internal_nolock (ptr=0x897040, size=28)
at gmalloc.c:1394
#1 0x00636bd7 in _realloc_internal (ptr=0x897040, size=28) at gmalloc.c:1499
#2 0x00636c42 in realloc (ptr=0x897040, size=28) at gmalloc.c:1516
#3 0x00596856 in xrealloc (block=0x897040, size=28) at alloc.c:711
#4 0x00589648 in regex_compile (pattern=0xa7ec60 "site-lisp", size=9,
syntax=3408388, bufp=0x846258) at regex.c:3684
#5 0x0059556d in re_compile_pattern (pattern=0xa7ec60 "site-lisp", length=9,
bufp=0x846258) at regex.c:6361
#6 0x005768d0 in compile_pattern_1 (cp=0x846248, pattern=9810241,
translate=8930309, posix=0) at search.c:150
#7 0x00576b32 in compile_pattern (pattern=9810241, regp=0x8475d8,
translate=8930309, posix=0, multibyte=0) at search.c:245
#8 0x005771b8 in string_match_1 (regexp=9810241, string=9810337,
start=8968218, posix=0) at search.c:401
#9 0x005773ab in Fstring_match (regexp=9810241, string=9810337, start=8968218)
at search.c:451
#10 0x005e4f91 in init_lread () at lread.c:4111
#11 0x0052866c in main (argc=2, argv=0x2001cc00) at emacs.c:1467
(gdb) p _heapbase
$3 = 0x20000000 ""
(gdb) p block
$1 = 4294838425
The SEGV comes from the ridiculous value of block, which was calculated by the BLOCK macro.
=== modified file 'src/gmalloc.c'
--- src/gmalloc.c 2011-08-04 17:04:39 +0000
+++ src/gmalloc.c 2011-08-12 19:47:21 +0000
@@ -584,6 +584,12 @@
mcheck (NULL);
#endif
+#ifdef CYGWIN
+ if (bss_sbrk_did_unexec)
+ /* we're reinitializing the dumped emacs. */
+ memset (_fraghead, 0, BLOCKLOG * sizeof (struct list));
+#endif
+
if (__malloc_initialize_hook)
(*__malloc_initialize_hook) ();
@@ -1054,6 +1060,12 @@
if (ptr == NULL)
return;
+#ifdef CYGWIN
+ if (ptr < _heapbase)
+ /* we're being asked to free something in the static heap */
+ return;
+#endif
+
PROTECT_MALLOC_STATE (0);
LOCK_ALIGNED_BLOCKS ();
=== modified file 'src/unexcw.c'
--- src/unexcw.c 2011-03-17 20:18:59 +0000
+++ src/unexcw.c 2011-08-12 15:37:47 +0000
@@ -33,6 +33,8 @@
extern int bss_sbrk_did_unexec;
+extern int __malloc_initialized;
+
/* emacs symbols that indicate where bss and data end for emacs internals */
extern char my_endbss[];
extern char my_edata[];
@@ -210,9 +212,12 @@
lseek (fd, (long) (exe_header->section_header[i].s_scnptr),
SEEK_SET);
assert (ret != -1);
+ /* force the dumped emacs to reinitialize malloc */
+ __malloc_initialized = 0;
ret =
write (fd, (char *) start_address,
my_endbss - (char *) start_address);
+ __malloc_initialized = 1;
assert (ret == (my_endbss - (char *) start_address));
if (debug_unexcw)
printf (" .bss, mem start 0x%08x mem length %d\n",
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.