From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Vibhav Pant Newsgroups: gmane.emacs.devel Subject: Re: Critical bytecode bug with hash tables while dumping emacs. Date: Fri, 27 Jan 2017 00:27:27 +0530 Message-ID: References: <66c98f41-e9b3-2aa7-a2a2-4595dd4ee653@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1485457081 24890 195.159.176.226 (26 Jan 2017 18:58:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 26 Jan 2017 18:58:01 +0000 (UTC) Cc: Emacs development discussions To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 26 19:57:57 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWpEn-0004fa-Px for ged-emacs-devel@m.gmane.org; Thu, 26 Jan 2017 19:57:37 +0100 Original-Received: from localhost ([::1]:40635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cWpEt-0000XR-2P for ged-emacs-devel@m.gmane.org; Thu, 26 Jan 2017 13:57:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cWpEg-0000UZ-JX for emacs-devel@gnu.org; Thu, 26 Jan 2017 13:57:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cWpEf-0003V6-6y for emacs-devel@gnu.org; Thu, 26 Jan 2017 13:57:30 -0500 Original-Received: from mail-yb0-x235.google.com ([2607:f8b0:4002:c09::235]:34659) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cWpEf-0003Uv-2z for emacs-devel@gnu.org; Thu, 26 Jan 2017 13:57:29 -0500 Original-Received: by mail-yb0-x235.google.com with SMTP id j82so53350927ybg.1 for ; Thu, 26 Jan 2017 10:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T5z1+lgDJvK4+fJXY/AtS0+AvuxoRcZgyMiKADvNGK0=; b=WElZ3mm1bXfR1N8g5G6NrnVHo5w/hde8xcJ32AdePBaSE4RwKIH4dKdHoVWrvCxMFr gJap/f2sigdots+/G+tPVNN/ebPz5xeQdjdwzc1N7xKGIJyFoZNmOejIXVCqSBIQlGQ9 Z+bmijRNsLTbz/Cf7/o73HvWjtdcp/RFM4c/i9efbbxOvAo6nQGjsvRkFGdK8dJfoQsM bqVOa7k0OFD4ujtDuSXwZrnIfxU9AP/lQysP+Aua6tpxg1SSIl0U8Fom29Va0/QjjXXt k5FU9JWfzV/+O5Qlzas48MARrvKzoZAUkHiZT+OXXYqD/td9KhknziHmNLPuwMNgTMPO TewQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T5z1+lgDJvK4+fJXY/AtS0+AvuxoRcZgyMiKADvNGK0=; b=D4Ya+HvdWwAfdhnGswQ6+71TVvvwRzQPH2oKMb06PL2Xg8N2Uv4ynFqr8cDLxws02n cvz4Ow4cO/CRdi5mccwSA+9FJ5I2+dOcE3ZjnKHiDeQ0aX9uqf7uUoPtUww1cB4mSxAt lpcJrTK6aulkOfGpVh/qL5DzOitW/nfJrEDiSSVpWpt8WYmBGuu6LUKOj745lNXZTEIA MyXdCYc1pEJhPVLwPiMLKmIPDuSkIPZetHWn440JDGpcvPbYMfKG6/Zz71/2wTGMq2Zv KQLIUjs6xuybLnm7z8qQZuJhehHLTBsrVxkSp28GgG2P5eNrqp8a5hpCTgXSc86kEup4 q8IQ== X-Gm-Message-State: AIkVDXIBFJU5uPTkkeK61mKk+IjoXAafZll5d9eGVyU42Cf9/2zvU0/AQbGXlcRFfyaML3mOxpFA2l37guaRfw== X-Received: by 10.129.174.90 with SMTP id g26mr3476832ywk.25.1485457048105; Thu, 26 Jan 2017 10:57:28 -0800 (PST) Original-Received: by 10.129.153.77 with HTTP; Thu, 26 Jan 2017 10:57:27 -0800 (PST) In-Reply-To: <66c98f41-e9b3-2aa7-a2a2-4595dd4ee653@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4002:c09::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211622 Archived-At: On Thu, Jan 26, 2017 at 11:03 PM, Paul Eggert wrote: > In that case the bug is not critical, right? One way to address the problem > is to say that code should not print hash tables before dumping. It's critical in the sense that any code loaded from loadup.el is effectively prohibited from using printed hash tables in any way. I've recently been working on adding a new 'switch` bytecode op (@ branch feature/byte-switch), which uses hash tables generated during compile time (so the constant vector stores printed hash tables) as jump tables. This bug breaks switch entirely. > we're planning to redo dumping anyway and can address this problem (if it still > occurs) then. I suspect this bug is related to purecopy, which I suppose isn't a part of the redo (or is it? I don't know much about the new dumping code). If anyone has any ideas about this issue, I'd appreciate some pointers on where to start. Thanks, Vibhav -- Vibhav Pant vibhavp@gmail.com