all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pip Cet <pipcet@gmail.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 42832@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
Subject: bug#42832: 28.0.50; "Bus error" when compiling Emacs now on Debian bullseye
Date: Fri, 14 Aug 2020 15:01:44 +0000	[thread overview]
Message-ID: <CAOqdjBdNPJhAa6h7XQC5L4D8vb_yLyXT2miXTZc+NdS1SDSzxQ@mail.gmail.com> (raw)
In-Reply-To: <CAOqdjBcq56XCi6ecs-pY-2sM-45n7-nbo2g3cPi6yCOhLvKwHw@mail.gmail.com>

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

On Fri, Aug 14, 2020 at 2:24 PM Pip Cet <pipcet@gmail.com> wrote:
> If no, any ideas on how to fix it? The obvious fix would be to always
> mark all pdumped objects, but that has a performance cost. Less
> obvious would be clearing the memory in the pdumper image that belongs
> to an object that's being "freed", or keeping track of which pdumper
> objects are still valid after GC...

I've gone with the last idea. This patch should fix things, though
given how difficult the bug is to trigger reliably it might also
merely appear to fix it...

[-- Attachment #2: 0001-Try-to-avoid-marking-zombie-pdumper-objects.patch --]
[-- Type: text/x-patch, Size: 2813 bytes --]

From e5e7445625c4727067b6e056bf736a2c8db37602 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Fri, 14 Aug 2020 14:56:19 +0000
Subject: [PATCH] Try to avoid marking zombie pdumper objects.

---
 src/pdumper.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/src/pdumper.c b/src/pdumper.c
index bc41afc7c5..812eb18de9 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -4871,6 +4871,8 @@ dump_bitset_clear (struct dump_bitset *bitset)
   struct dump_header header;
   /* Mark bits for objects in the dump; used during GC.  */
   struct dump_bitset mark_bits;
+  /* Mark bits for objects in the dump; used during GC.  */
+  struct dump_bitset last_mark_bits;
   /* Time taken to load the dump.  */
   double load_time;
   /* Dump file name.  */
@@ -4995,6 +4997,9 @@ pdumper_find_object_type_impl (const void *obj)
     return PDUMPER_NO_OBJECT;
   const struct dump_reloc *reloc =
     dump_find_relocation (&dump_private.header.object_starts, offset);
+  ptrdiff_t bitno = offset / DUMP_ALIGNMENT;
+  if (!dump_bitset_bit_set_p (&dump_private.last_mark_bits, bitno))
+    return PDUMPER_NO_OBJECT;
   return (reloc != NULL && dump_reloc_get_offset (*reloc) == offset)
     ? reloc->type
     : PDUMPER_NO_OBJECT;
@@ -5021,12 +5026,16 @@ pdumper_set_marked_impl (const void *obj)
   eassert (offset < dump_private.header.cold_start);
   eassert (offset < dump_private.header.discardable_start);
   ptrdiff_t bitno = offset / DUMP_ALIGNMENT;
+  eassert (dump_bitset_bit_set_p (&dump_private.last_mark_bits, bitno));
   dump_bitset_set_bit (&dump_private.mark_bits, bitno);
 }
 
 void
 pdumper_clear_marks_impl (void)
 {
+  memcpy (dump_private.last_mark_bits.bits, dump_private.mark_bits.bits,
+	  sizeof (dump_private.last_mark_bits.bits[0])
+	  * dump_private.mark_bits.number_words);
   dump_bitset_clear (&dump_private.mark_bits);
 }
 
@@ -5244,6 +5253,7 @@ pdumper_load (const char *dump_filename)
   dump_off adj_discardable_start;
 
   struct dump_bitset mark_bits;
+  struct dump_bitset last_mark_bits;
   size_t mark_bits_needed;
 
   struct dump_header header_buf = { 0 };
@@ -5360,12 +5370,18 @@ pdumper_load (const char *dump_filename)
   if (!dump_bitset_init (&mark_bits, mark_bits_needed))
     goto out;
 
+  if (!dump_bitset_init (&last_mark_bits, mark_bits_needed))
+    goto out;
+
+  memset (last_mark_bits.bits, 0xff, sizeof (last_mark_bits.bits[0] * last_mark_bits.number_words));
+
   /* Point of no return.  */
   err = PDUMPER_LOAD_SUCCESS;
   dump_base = (uintptr_t) sections[DS_HOT].mapping;
   gflags.dumped_with_pdumper_ = true;
   dump_private.header = *header;
   dump_private.mark_bits = mark_bits;
+  dump_private.last_mark_bits = last_mark_bits;
   dump_public.start = dump_base;
   dump_public.end = dump_public.start + dump_size;
 
-- 
2.28.0


  reply	other threads:[~2020-08-14 15:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12 17:12 bug#42832: 28.0.50; "Bus error" when compiling Emacs now on Debian bullseye Lars Ingebrigtsen
2020-08-12 18:22 ` Lars Ingebrigtsen
2020-08-12 18:30   ` Lars Ingebrigtsen
2020-08-12 18:50     ` Eli Zaretskii
2020-08-12 18:58       ` Lars Ingebrigtsen
2020-08-12 19:28         ` Lars Ingebrigtsen
2020-08-12 19:33           ` Lars Ingebrigtsen
2020-08-12 20:40             ` Paul Eggert
2020-08-12 20:47               ` Lars Ingebrigtsen
2020-08-12 21:42                 ` Pip Cet
2020-08-12 21:54                   ` Lars Ingebrigtsen
2020-08-13 10:05                     ` Pip Cet
2020-08-13 10:12                       ` Lars Ingebrigtsen
2020-08-13 10:15                         ` Lars Ingebrigtsen
2020-08-13 14:08                           ` Pip Cet
2020-08-14 11:48                             ` Lars Ingebrigtsen
2020-08-14 12:05                               ` Pip Cet
2020-08-14 12:34                                 ` Lars Ingebrigtsen
2020-08-14 14:24                             ` Pip Cet
2020-08-14 15:01                               ` Pip Cet [this message]
2020-08-14 15:37                                 ` Lars Ingebrigtsen
2020-08-14 19:08                                   ` Pip Cet
2020-08-14 19:35                                     ` Lars Ingebrigtsen
2020-08-14 21:10                                     ` Lars Ingebrigtsen
2020-08-14 21:48                                     ` Paul Eggert
2020-08-14 22:25                                       ` Pip Cet
2020-08-14 22:52                                         ` Paul Eggert
2020-08-12 22:00                   ` Lars Ingebrigtsen
2020-08-12 18:34   ` Eli Zaretskii
2020-08-12 18:41     ` Lars Ingebrigtsen
2020-08-12 19:26 ` Andreas Schwab

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

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

  git send-email \
    --in-reply-to=CAOqdjBdNPJhAa6h7XQC5L4D8vb_yLyXT2miXTZc+NdS1SDSzxQ@mail.gmail.com \
    --to=pipcet@gmail.com \
    --cc=42832@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.