From: Pip Cet <pipcet@gmail.com>
To: Noam Postavsky <npostavs@gmail.com>
Cc: Michael Heerdegen <michael_heerdegen@web.de>, 36447@debbugs.gnu.org
Subject: bug#36447: 27.0.50; New "Unknown keyword" errors
Date: Tue, 2 Jul 2019 22:50:54 +0000 [thread overview]
Message-ID: <CAOqdjBeZgdZemt0H9xqnVcMhugD7nAHPVap_B42z3LWOGf5ZNQ@mail.gmail.com> (raw)
In-Reply-To: <85d0is5ry1.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]
On Tue, Jul 2, 2019 at 4:20 PM Noam Postavsky <npostavs@gmail.com> wrote:
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> > Pip Cet <pipcet@gmail.com> writes:
> >> > Hmm - seems so, yes. I just made bootstrap with the commit
> >> > included, and the problem is still gone. Strange thing, but seems
> >> > there is nothing to fix.
> >>
> >> I'm not sure I agree. Something went wrong somewhere, or we wouldn't
> >> have called byte code with what looks like an invalid hash table.
> >
> > Did you reply to the wrong thread - or - where is a connection to hash
> > tables?
>
> The compiler translates repeated `eq' in a cond like that into a hash
> and jump. See byte-compile-cond-use-jump-table.
I think I found the problem. It's a bit tricky.
When we purecopy the hash tables emitted by the byte code compiler,
Vpurify_flag is a hash table with predicate 'equal. That means the
->next vectors for different hash tables now might refer to the same
pure vector.
Rehashing such a hash table thus destroys another hash table's ->next
vector, so it shouldn't happen.
pdumper.c forces rehashing of many hash tables, including pure ones.
The attached patch "fixes" things, at a high price. I'll try coming up
with a proper fix soon if no one beats me to it.
(To reproduce the problem, I added these lines to fn.c:
DEFSYM (QCrehash_size, ":rehash-size");
DEFSYM (QCrehash_threshold, ":rehash-threshold");
DEFSYM (QCweakness, ":weakness");
+ DEFSYM (QCgroup, ":group");
+ DEFSYM (QCversion, ":version");
+ DEFSYM (QCpackage_version, ":package-version");
+ DEFSYM (QClink, ":link");
+ DEFSYM (QCload, ":load");
+ DEFSYM (QCtag, ":tag");
+ DEFSYM (QCset_after, ":set-after");
DEFSYM (Qkey, "key");
DEFSYM (Qvalue, "value"); )
[-- Attachment #2: 0001-Fix-bug-36477.patch --]
[-- Type: text/x-patch, Size: 781 bytes --]
From 20b63dce1695cfc2dfa94961d03da88a4cceaffb Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@gmail.com>
Date: Tue, 2 Jul 2019 22:48:23 +0000
Subject: [PATCH] Fix bug#36477
---
src/fns.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/fns.c b/src/fns.c
index 2fc000a7f4..375b7d2841 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -4223,6 +4223,11 @@ hash_table_rehash (struct Lisp_Hash_Table *h)
{
ptrdiff_t size = HASH_TABLE_SIZE (h);
+ h->next = Fcopy_sequence (h->next);
+ h->index = Fcopy_sequence (h->index);
+ h->hash = Fcopy_sequence (h->hash);
+ h->key_and_value = Fcopy_sequence (h->key_and_value);
+
/* Recompute the actual hash codes for each entry in the table.
Order is still invalid. */
for (ptrdiff_t i = 0; i < size; ++i)
--
2.20.1
next prev parent reply other threads:[~2019-07-02 22:50 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-30 18:23 bug#36447: 27.0.50; New "Unknown keyword" errors Michael Heerdegen
2019-06-30 18:43 ` Eli Zaretskii
2019-06-30 21:44 ` Michael Heerdegen
2019-07-01 12:25 ` Noam Postavsky
2019-07-01 13:20 ` Pip Cet
2019-07-01 22:04 ` Michael Heerdegen
2019-07-02 1:59 ` Stefan Kangas
2019-07-02 14:17 ` Eli Zaretskii
2019-07-02 13:29 ` Pip Cet
2019-07-02 15:35 ` Michael Heerdegen
2019-07-02 16:20 ` Noam Postavsky
2019-07-02 22:50 ` Pip Cet [this message]
2019-07-03 11:57 ` Pip Cet
2019-07-05 1:59 ` Michael Heerdegen
2019-07-05 6:35 ` Pip Cet
2019-07-05 7:50 ` Eli Zaretskii
2019-07-05 8:12 ` Pip Cet
2019-07-05 8:25 ` Eli Zaretskii
2019-07-05 8:36 ` Pip Cet
2019-07-05 8:41 ` Eli Zaretskii
2019-07-05 9:09 ` Pip Cet
2019-07-05 12:23 ` Robert Pluim
2019-07-05 12:33 ` Eli Zaretskii
2019-07-05 13:41 ` Pip Cet
2019-07-05 18:00 ` Stefan Monnier
2019-07-05 18:07 ` Eli Zaretskii
2019-07-05 20:16 ` Stefan Monnier
2019-07-05 18:57 ` Pip Cet
2019-07-05 19:13 ` Eli Zaretskii
2019-07-05 20:21 ` Stefan Monnier
2019-07-05 21:52 ` Pip Cet
2019-07-05 22:10 ` Stefan Monnier
2019-07-06 6:45 ` Eli Zaretskii
2019-07-06 15:08 ` Pip Cet
2019-07-09 21:05 ` Stefan Monnier
2019-07-10 2:38 ` Eli Zaretskii
2019-07-10 3:19 ` Daniel Colascione
2019-07-10 15:01 ` Pip Cet
2019-07-10 17:16 ` Daniel Colascione
2019-07-10 20:14 ` Pip Cet
2019-07-06 15:32 ` Michael Heerdegen
2019-07-08 17:30 ` Lars Ingebrigtsen
2019-07-08 17:58 ` Pip Cet
2019-07-08 22:18 ` Lars Ingebrigtsen
2019-07-08 22:25 ` Noam Postavsky
2019-07-09 14:00 ` Pip Cet
2019-07-10 3:01 ` Daniel Colascione
2019-07-14 14:06 ` Noam Postavsky
2019-07-08 23:22 ` Stefan Monnier
2019-07-08 22:23 ` Michael Heerdegen
2019-07-09 15:43 ` Eli Zaretskii
2019-07-09 20:15 ` Stefan Monnier
2019-07-05 7:55 ` Katsumi Yamaoka
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=CAOqdjBeZgdZemt0H9xqnVcMhugD7nAHPVap_B42z3LWOGf5ZNQ@mail.gmail.com \
--to=pipcet@gmail.com \
--cc=36447@debbugs.gnu.org \
--cc=michael_heerdegen@web.de \
--cc=npostavs@gmail.com \
/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.