unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "9273@debbugs.gnu.org" <9273@debbugs.gnu.org>
Subject: bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime
Date: Fri, 12 Aug 2011 16:24:20 -0400	[thread overview]
Message-ID: <4E458BF4.9080108@cornell.edu> (raw)
In-Reply-To: <4E451A1F.4060409@cornell.edu>

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	other threads:[~2011-08-12 20:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-09 20:09 bug#9273: 23.3; malloc initialization should (sometimes) happen at runtime Ken Brown
2011-08-10  0:24 ` Richard Stallman
2011-08-10 15:56 ` Eli Zaretskii
2011-08-10 17:52   ` Ken Brown
2011-08-10 18:10     ` Eli Zaretskii
2011-08-10 18:49       ` Ken Brown
2011-08-11 21:45   ` Ken Brown
2011-08-12  6:54     ` Eli Zaretskii
2011-08-12 10:10       ` Ken Brown
2011-08-12 11:33         ` Eli Zaretskii
2011-08-12 12:18           ` Ken Brown
2011-08-12 20:24             ` Ken Brown [this message]
2011-08-13  8:05               ` Eli Zaretskii
2011-08-13 13:48                 ` Ken Brown
2011-08-13 14:41                   ` Eli Zaretskii
2011-08-13 14:53                     ` Ken Brown
2011-08-13 15:07                       ` Stefan Monnier
2011-08-13 15:33                         ` Ken Brown
2011-08-13 19:19                           ` Stefan Monnier
2011-08-14  3:13                             ` Ken Brown
2011-08-16 13:30                               ` Ken Brown
2011-08-12 23:51 ` grischka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E458BF4.9080108@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=9273@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).