From: Vibhav Pant <vibhavp@gmail.com>
To: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Critical bytecode bug with hash tables while dumping emacs.
Date: Thu, 26 Jan 2017 18:33:33 +0530 [thread overview]
Message-ID: <CA+T2Sh1jbBv2q4+8FXaZnZ0eLKM1W2vvTFKq-0EWv01rMLwQWg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
While, working on `byte-switch`, I discovered a critical bug when a
hash table is present in the constant vector of a bytecode function.
If such a function is called when temacs dumps a binary during the
biuld process, all keys and their corresponding values change to that
of a different hash table. The following patch demonstrates this by
testing the value of 'foo` in a table mapping 'foo to 'bar, and
erroring out if the test fails. This causes temacs to error out,
failing the build.
Since the current elisp codebase, doesn't use printed representation
anywhere to represent hash tables, this bug doesn't come up. However,
this may fail builds in the future, if future code does that.
--
Vibhav Pant
vibhavp@gmail.com
[-- Attachment #2: wrong-hash-table.patch --]
[-- Type: text/x-patch, Size: 683 bytes --]
diff --git a/lisp/custom.el b/lisp/custom.el
index 70b6839db3..49330bb1a4 100644
--- a/lisp/custom.el
+++ b/lisp/custom.el
@@ -146,6 +146,10 @@ custom-declare-variable
set to nil, as the value is no longer rogue."
(put symbol 'standard-value (purecopy (list default)))
;; Maybe this option was rogue in an earlier version. It no longer is.
+ (let ((ht #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8 data
+ (foo bar))))
+ (unless (eq 'bar (gethash 'foo ht))
+ (error (format "This shouldn't be happening. Hash table: %s" ht))))
(when (get symbol 'force-value)
(put symbol 'force-value nil))
(if (keywordp doc)
next reply other threads:[~2017-01-26 13:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 13:03 Vibhav Pant [this message]
2017-01-26 17:33 ` Critical bytecode bug with hash tables while dumping emacs Paul Eggert
2017-01-26 18:57 ` Vibhav Pant
2017-01-27 13:45 ` Vibhav Pant
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=CA+T2Sh1jbBv2q4+8FXaZnZ0eLKM1W2vvTFKq-0EWv01rMLwQWg@mail.gmail.com \
--to=vibhavp@gmail.com \
--cc=emacs-devel@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 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.