bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Fri, 12 Aug 2011 16:24:20 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0

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@cornell.edu>
>>> CC: "9273@debbugs.gnu.org"<9273@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@cornell.edu>
>>>>> CC: "9273@debbugs.gnu.org"<9273@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",








reply via email to

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