unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 49261@debbugs.gnu.org
Subject: bug#49261: Segfault during loadup
Date: Sun, 11 Jul 2021 01:36:21 -0700	[thread overview]
Message-ID: <e34a6a2d-6d6e-ac13-313d-b3dc5c6af318@cs.ucla.edu> (raw)
In-Reply-To: <87h7h51x9y.fsf_-_@gnus.org>

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On 7/7/21 5:09 PM, Lars Ingebrigtsen wrote:
> There seems to be a corruption in the hash tables somewhere.  It's
> totally reproducible with the recipe

Thanks for the recipe; it let me reproduce the problem on Fedora 34 x86-64.

The problem comes from the fact that mark_maybe_pointer works 
differently on pdumper objects than it works on ordinary objects. On 
ordinary objects, roots can point anywhere into an object (because this 
sort of thing has happened on real machines), whereas on pdumper 
objects, roots had to point to the start of the object.

I worked around this particular problem changing mark_maybe_pointer so 
that pdumper roots can also be tagged (see first attached patch). 
However, I suspect this is not a complete fix, as it doesn't cover the 
case where a root points to some part of a pdumper object that is not at 
the object's start. I added a FIXME about this. Perhaps Daniel can take 
a look at it sometime. I think the remaining bug will be hit only rarely 
(if ever).

The second attached patch is in the same area, but is not part of the 
fix. It causes the GC to be a bit more accurate (i.e., less 
conservative) for roots, which can help avoid some leaks.

[-- Attachment #2: 0001-Fix-pdumper-related-GC-bug.patch --]
[-- Type: text/x-patch, Size: 1623 bytes --]

From 2f7afef5ffe023a7a12520201ab70643f826abfd Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 11 Jul 2021 00:27:43 -0700
Subject: [PATCH 1/2] Fix pdumper-related GC bug
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/alloc.c (mark_maybe_pointer): Also mark pointers
to pdumper objects, even when the pointers are tagged.
Add a FIXME saying why this isn’t enough.
---
 src/alloc.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/src/alloc.c b/src/alloc.c
index 76d8c7ddd1..752eaec135 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -4755,6 +4755,17 @@ mark_maybe_pointer (void *p)
      definitely _don't_ have an object.  */
   if (pdumper_object_p (p))
     {
+      /* FIXME: This code assumes that every reachable pdumper object
+	 is addressed either by a pointer to the object start, or by
+	 the same pointer with an LSB-style tag.  This assumption
+	 fails if a pdumper object is reachable only via machine
+	 addresses of non-initial object components.  Although such
+	 addressing is rare in machine code generated by C compilers
+	 from Emacs source code, it can occur in some cases.  To fix
+	 this problem, the pdumper code should grok non-initial
+	 addresses, as the non-pdumper code does.  */
+      uintptr_t mask = VALMASK;
+      p = (void *) ((uintptr_t) p & mask);
       /* Don't use pdumper_object_p_precise here! It doesn't check the
          tag bits. OBJ here might be complete garbage, so we need to
          verify both the pointer and the tag.  */
-- 
2.31.1


[-- Attachment #3: 0002-Make-pdumper-marking-pickier.patch --]
[-- Type: text/x-patch, Size: 4037 bytes --]

From f6472cc8e2fdcfd7365240783f34e101fe44142b Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 11 Jul 2021 00:54:32 -0700
Subject: [PATCH 2/2] Make pdumper-marking pickier
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Prevent some false-positives in conservative GC marking.
This doesn’t fix any correctness bugs; it’s merely to
reclaim some memory instead of keeping it unnecessarily.
* src/alloc.c (mark_maybe_pointer): New arg SYMBOL_ONLY.
All callers changed.  Check that the pointer’s tag, if any,
matches the pdumper-reported type.
---
 src/alloc.c | 34 +++++++++++++++++++++++++---------
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/src/alloc.c b/src/alloc.c
index 752eaec135..b3668d2131 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -4740,7 +4740,7 @@ live_small_vector_p (struct mem_node *m, void *p)
    marked.  */
 
 static void
-mark_maybe_pointer (void *p)
+mark_maybe_pointer (void *p, bool symbol_only)
 {
   struct mem_node *m;
 
@@ -4765,15 +4765,21 @@ mark_maybe_pointer (void *p)
 	 this problem, the pdumper code should grok non-initial
 	 addresses, as the non-pdumper code does.  */
       uintptr_t mask = VALMASK;
-      p = (void *) ((uintptr_t) p & mask);
+      void *po = (void *) ((uintptr_t) p & mask);
+      char *cp = p;
+      char *cpo = po;
       /* Don't use pdumper_object_p_precise here! It doesn't check the
          tag bits. OBJ here might be complete garbage, so we need to
          verify both the pointer and the tag.  */
-      int type = pdumper_find_object_type (p);
-      if (pdumper_valid_object_type_p (type))
-        mark_object (type == Lisp_Symbol
-                     ? make_lisp_symbol (p)
-                     : make_lisp_ptr (p, type));
+      int type = pdumper_find_object_type (po);
+      if (pdumper_valid_object_type_p (type)
+	  && (!USE_LSB_TAG || p == po || cp - cpo == type))
+	{
+	  if (type == Lisp_Symbol)
+	    mark_object (make_lisp_symbol (po));
+	  else if (!symbol_only)
+	    mark_object (make_lisp_ptr (po, type));
+	}
       return;
     }
 
@@ -4791,6 +4797,8 @@ mark_maybe_pointer (void *p)
 
 	case MEM_TYPE_CONS:
 	  {
+	    if (symbol_only)
+	      return;
 	    struct Lisp_Cons *h = live_cons_holding (m, p);
 	    if (!h)
 	      return;
@@ -4800,6 +4808,8 @@ mark_maybe_pointer (void *p)
 
 	case MEM_TYPE_STRING:
 	  {
+	    if (symbol_only)
+	      return;
 	    struct Lisp_String *h = live_string_holding (m, p);
 	    if (!h)
 	      return;
@@ -4818,6 +4828,8 @@ mark_maybe_pointer (void *p)
 
 	case MEM_TYPE_FLOAT:
 	  {
+	    if (symbol_only)
+	      return;
 	    struct Lisp_Float *h = live_float_holding (m, p);
 	    if (!h)
 	      return;
@@ -4827,6 +4839,8 @@ mark_maybe_pointer (void *p)
 
 	case MEM_TYPE_VECTORLIKE:
 	  {
+	    if (symbol_only)
+	      return;
 	    struct Lisp_Vector *h = live_large_vector_holding (m, p);
 	    if (!h)
 	      return;
@@ -4836,6 +4850,8 @@ mark_maybe_pointer (void *p)
 
 	case MEM_TYPE_VECTOR_BLOCK:
 	  {
+	    if (symbol_only)
+	      return;
 	    struct Lisp_Vector *h = live_small_vector_holding (m, p);
 	    if (!h)
 	      return;
@@ -4897,7 +4913,7 @@ mark_memory (void const *start, void const *end)
   for (pp = start; (void const *) pp < end; pp += GC_POINTER_ALIGNMENT)
     {
       void *p = *(void *const *) pp;
-      mark_maybe_pointer (p);
+      mark_maybe_pointer (p, false);
 
       /* Unmask any struct Lisp_Symbol pointer that make_lisp_symbol
 	 previously disguised by adding the address of 'lispsym'.
@@ -4906,7 +4922,7 @@ mark_memory (void const *start, void const *end)
 	 non-adjacent words and P might be the low-order word's value.  */
       intptr_t ip;
       INT_ADD_WRAPV ((intptr_t) p, (intptr_t) lispsym, &ip);
-      mark_maybe_pointer ((void *) ip);
+      mark_maybe_pointer ((void *) ip, true);
     }
 }
 
-- 
2.31.1


  parent reply	other threads:[~2021-07-11  8:36 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 17:38 bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains Mallchad Skeghyeph
2021-06-30 13:00 ` Lars Ingebrigtsen
2021-06-30 13:26   ` Eli Zaretskii
2021-06-30 14:08     ` Lars Ingebrigtsen
     [not found]       ` <CADrO7Mje3DstmjxutZcpx33jWJwgE_z+hGfJc4aON1CYOpyJxA@mail.gmail.com>
2021-07-01 10:55         ` Lars Ingebrigtsen
2021-07-01 12:58           ` Eli Zaretskii
2021-06-30 16:07     ` Michael Albinus
2021-06-30 16:16       ` Eli Zaretskii
2021-07-01 11:38         ` Lars Ingebrigtsen
2021-06-30 19:31   ` Juri Linkov
2021-07-01 16:57   ` Michael Albinus
2021-07-01 18:31     ` Eli Zaretskii
2021-07-02 11:06       ` Lars Ingebrigtsen
2021-07-02 12:32         ` Michael Albinus
2021-07-07 16:01         ` Lars Ingebrigtsen
2021-07-07 16:07           ` Michael Albinus
2021-07-07 16:13             ` Lars Ingebrigtsen
2021-07-07 16:40               ` Michael Albinus
2021-07-07 16:57                 ` Lars Ingebrigtsen
2021-07-07 16:55           ` Michael Albinus
2021-07-07 16:59             ` Lars Ingebrigtsen
2021-07-07 17:36               ` Michael Albinus
2021-07-07 18:08                 ` Lars Ingebrigtsen
2021-07-07 18:33                   ` Eli Zaretskii
2021-07-07 18:50                     ` Lars Ingebrigtsen
2021-07-07 19:40                 ` Lars Ingebrigtsen
2021-07-07 20:03                   ` Michael Albinus
2021-07-08  6:03                     ` Michael Albinus
2021-07-08 19:53                       ` Michael Albinus
2021-07-09  6:30                         ` Eli Zaretskii
2021-07-09  8:28                           ` Michael Albinus
2021-07-09 10:45                             ` Eli Zaretskii
2021-07-09 11:01                               ` Michael Albinus
2021-07-09 16:31                                 ` Lars Ingebrigtsen
2021-07-12 13:53                                   ` Michael Albinus
2021-07-12 14:03                                     ` Eli Zaretskii
2021-07-12 14:37                                       ` Michael Albinus
2021-07-12 17:30                                         ` Eli Zaretskii
2021-07-12 17:35                                           ` Lars Ingebrigtsen
2021-07-12 17:38                                             ` Eli Zaretskii
2021-07-12 18:00                                               ` Michael Albinus
2021-07-12 18:25                                                 ` Eli Zaretskii
2021-07-12 18:46                                                   ` Michael Albinus
2021-07-12 19:04                                                     ` Eli Zaretskii
2021-07-13 17:53                                                       ` Michael Albinus
2021-07-13 16:30                                               ` Lars Ingebrigtsen
2021-07-13 16:31                                                 ` Lars Ingebrigtsen
2021-07-13 16:41                                                 ` Eli Zaretskii
2021-07-13 17:59                                                   ` Michael Albinus
2021-07-13 19:00                                                     ` Eli Zaretskii
2021-07-13 19:09                                                       ` Lars Ingebrigtsen
2021-07-13 19:36                                                       ` Michael Albinus
2021-07-13 17:55                                                 ` Michael Albinus
2021-07-13 19:05                                                   ` Lars Ingebrigtsen
2021-07-16 16:15                                                     ` Michael Albinus
2021-07-17 14:06                                                       ` Lars Ingebrigtsen
2021-07-07 20:05                   ` Eli Zaretskii
2021-07-07 20:09                     ` Lars Ingebrigtsen
2021-07-07 20:15                       ` Eli Zaretskii
2021-07-07 20:10                     ` Eli Zaretskii
2021-07-07 20:18                       ` Lars Ingebrigtsen
2021-07-07 20:29                         ` Lars Ingebrigtsen
2021-07-07 20:37                           ` Lars Ingebrigtsen
2021-07-07 20:55                             ` Lars Ingebrigtsen
2021-07-07 21:04                               ` Lars Ingebrigtsen
2021-07-07 22:22                                 ` Lars Ingebrigtsen
2021-07-08  0:09                                   ` bug#49261: Segfault during loadup Lars Ingebrigtsen
2021-07-08  6:35                                     ` Eli Zaretskii
2021-07-08 12:51                                       ` Lars Ingebrigtsen
2021-07-11  8:36                                     ` Paul Eggert [this message]
2021-07-11 10:21                                       ` Eli Zaretskii
2021-07-11 15:25                                         ` Eli Zaretskii
2021-07-12  7:16                                           ` Paul Eggert
2021-07-12 12:07                                             ` Eli Zaretskii
2021-07-12 14:50                                               ` Paul Eggert
2021-07-12 14:56                                                 ` Andreas Schwab
2021-07-12 15:54                                                 ` Eli Zaretskii
2021-07-13 23:12                                                   ` Paul Eggert
2021-07-14  7:42                                                     ` Andreas Schwab
2021-07-14 22:04                                                       ` Paul Eggert
2021-07-14 22:10                                                         ` Andreas Schwab
2021-07-14 12:36                                                     ` Eli Zaretskii
2021-07-14 22:24                                                       ` Paul Eggert
2021-07-15  6:13                                                         ` Eli Zaretskii
2021-07-11 11:32                                       ` Lars Ingebrigtsen
2021-07-08  6:15                                   ` bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains Eli Zaretskii
2021-07-08  6:20                                 ` Eli Zaretskii
2021-07-08 12:44                                   ` Lars Ingebrigtsen
2021-07-08 13:11                                     ` Lars Ingebrigtsen
2021-07-08 13:13                                     ` Eli Zaretskii
2021-07-08  6:17                               ` Eli Zaretskii
2021-07-08 12:42                                 ` Lars Ingebrigtsen
2021-07-08 12:49                                   ` Lars Ingebrigtsen
2021-07-08 13:16                                   ` Eli Zaretskii
2021-07-08 13:34                                     ` Lars Ingebrigtsen
2021-07-08 16:47                                       ` Eli Zaretskii
2021-07-10 16:25                                         ` Lars Ingebrigtsen
2021-07-10 17:04                                           ` Eli Zaretskii
2021-07-10 17:15                                             ` Lars Ingebrigtsen
2021-07-10 17:20                                               ` Eli Zaretskii
2021-07-07 18:02           ` Eli Zaretskii
2021-07-07 18:17             ` Lars Ingebrigtsen
2021-07-07 18:20               ` Lars Ingebrigtsen
2021-07-07 18:42               ` Eli Zaretskii
2021-07-07 18:58                 ` Lars Ingebrigtsen
2021-07-07 19:03                   ` Lars Ingebrigtsen
2021-07-07 19:20                   ` Eli Zaretskii
2021-07-07 18:50               ` Eli Zaretskii
2021-07-07 19:22                 ` Lars Ingebrigtsen

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=e34a6a2d-6d6e-ac13-313d-b3dc5c6af318@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=49261@debbugs.gnu.org \
    --cc=larsi@gnus.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).