From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#36447: 27.0.50; New "Unknown keyword" errors Date: Fri, 05 Jul 2019 14:00:22 -0400 Message-ID: References: <875zon7x0a.fsf@web.de> <8336jqgbhp.fsf@gnu.org> <87h886eoke.fsf@web.de> <87d0iu54d1.fsf@gmail.com> <87k1d14djr.fsf@web.de> <87h884fo0i.fsf@web.de> <85d0is5ry1.fsf@gmail.com> <87lfxdgs1k.fsf@web.de> <83y31capj1.fsf@gnu.org> <83tvc0anwi.fsf@gnu.org> <83r274an61.fsf@gnu.org> <83pnmoacft.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="31992"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: michael_heerdegen@web.de, npostavs@gmail.com, Pip Cet , 36447@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 05 20:01:52 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hjSWt-00087c-VX for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Jul 2019 20:01:52 +0200 Original-Received: from localhost ([::1]:55188 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjSWq-0004Mi-T2 for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Jul 2019 14:01:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35789) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hjSWQ-0004Ke-F6 for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 14:01:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hjSWM-0000NL-GU for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 14:01:20 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44864) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hjSW9-0000E3-HM for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 14:01:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hjSW6-00028B-43 for bug-gnu-emacs@gnu.org; Fri, 05 Jul 2019 14:01:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jul 2019 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36447 X-GNU-PR-Package: emacs Original-Received: via spool by 36447-submit@debbugs.gnu.org id=B36447.15623496338141 (code B ref 36447); Fri, 05 Jul 2019 18:01:02 +0000 Original-Received: (at 36447) by debbugs.gnu.org; 5 Jul 2019 18:00:33 +0000 Original-Received: from localhost ([127.0.0.1]:53685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjSVc-00027F-M8 for submit@debbugs.gnu.org; Fri, 05 Jul 2019 14:00:33 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hjSVa-000270-Ov for 36447@debbugs.gnu.org; Fri, 05 Jul 2019 14:00:31 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4D45E4445DB; Fri, 5 Jul 2019 14:00:24 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C78194445D9; Fri, 5 Jul 2019 14:00:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1562349622; bh=CG7ybn7NVdjSpbz4rnVae8YNYSw0C4rMSxfGxZwAMn0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=kgcaSaCMjEH3XnJziuZoWP4HHBdc2f1+G6AazmR5+lQ78hHoAiUJaEFd58TqnaqgI W4rMUhkB/jWKQmhTwnE+/RlvIiirUL8hwXi/NukRCnF0r8ozYhb6IaQfnDAoV/MLdS mwHKGCEP0VbTW2QXFXn+GLk+TpCWpsS82TzbMY2TJHcSAprZC0UuU8cvUIiRFC13dq qNRN1E5DA4OLYU0HHXAD76LS9xeu/XIKmS0PXeTM0dPWfdIqjtP+0yWd5vVFr+Y8lh M8DKjtBa0OwdzOQgHxfJQixn5nQFLJS1Qt3AIEVoqPQ6LszQIBVSsyRvP6J/PUnuuA hOIbba7mZ6yWw== Original-Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9690C120130; Fri, 5 Jul 2019 14:00:22 -0400 (EDT) In-Reply-To: <83pnmoacft.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Jul 2019 15:33:10 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162140 Archived-At: > A na=EFve question: wouldn't the problem go away if we modified purecopy > not to do the above, i.e. not to merge the next vector of a hash table > with that of another? It might do the trick, yes (the patch below does that, for example, tho I think Pip's patch is a better approach). Note that it would mean we still modify data in the purespace, which ideally shouldn't happen. The problem fundamentally is that `purecopy` assumes that the argument passed to it will never again be modified (it doesn't have to be immutable before, but it should be afterwards) but if we rehash afterwards then we break this promise. >> The (disappointingly trivial) fix: >> call copy-sequence on h->next before rehashing the table. > Rehashing is not only done during dumping, right? The problem is not rehashing in general, but rehashing a purecopied hash-table. This should normally never be needed, since a purecopied hash-table should never be modified (no puthash/remhash should be applied to it), but sadly pdumper may need to recompute the hashes because objects's addresses may have changed between the dump and the reload. > So the fix you propose also makes rehashing slightly less efficient. In my patch I added a comment to explain that hash_table_rehash is not used in "normal" rehashing, but only in the rare case of rehashing on the first access to a preloaded hash-table, so the efficiency His patch looks good (probably better than mine). His patch can/should be made slightly more efficient by only doing the Fcopy_sequence on those hash-tables that are in purespace. Stefan diff --git a/src/fns.c b/src/fns.c index 2fc000a7f4..cc4fd7f2d7 100644 --- a/src/fns.c +++ b/src/fns.c @@ -4218,6 +4218,11 @@ maybe_resize_hash_table (struct Lisp_Hash_Table *h) } } =20 +/* Recompute the hashes (and hence also the "next" pointers). + Normally there's never a need to recompute hashes + This is done only on first-access to a hash-table loaded from + the "pdump", because the object's addresses may have changed, thus + affecting their hash. */ void hash_table_rehash (struct Lisp_Hash_Table *h) { diff --git a/src/alloc.c b/src/alloc.c index 64aaa8acdf..b0114a9459 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -5348,9 +5348,24 @@ purecopy_hash_table (struct Lisp_Hash_Table *table) =20 pure->header =3D table->header; pure->weak =3D purecopy (Qnil); + /* After reloading the pdumped data, objects may ehave changed location + in memory, so their hash may have changed. So the `hash`, `next`, and + `index` vectors are not immutable and can't safely be hash-cons'ed. = */ + if (HASH_TABLE_P (Vpurify_flag)) + { + Fremhash (table->hash, Vpurify_flag); + Fremhash (table->next, Vpurify_flag); + Fremhash (table->index, Vpurify_flag); + } pure->hash =3D purecopy (table->hash); pure->next =3D purecopy (table->next); pure->index =3D purecopy (table->index); + if (HASH_TABLE_P (Vpurify_flag)) + { + Fremhash (table->hash, Vpurify_flag); + Fremhash (table->next, Vpurify_flag); + Fremhash (table->index, Vpurify_flag); + } pure->count =3D table->count; pure->next_free =3D table->next_free; pure->pure =3D table->pure;