From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function Date: Mon, 29 Oct 2018 14:56:11 -0400 Message-ID: References: <87d0sh9hje.fsf@runbox.com> <83murjwplq.fsf@gnu.org> <87zhvjc4r3.fsf@runbox.com> <83y3b2uzyt.fsf@gnu.org> <87va65daw9.fsf@runbox.com> <8336t9vi3h.fsf@gnu.org> <87ftx89uqs.fsf@igel.home> <837eijtfw1.fsf@gnu.org> <878t2xd90z.fsf@runbox.com> <8336t4sfwy.fsf@gnu.org> <871s8ocbac.fsf@runbox.com> <83ftx3qj98.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540839321 19342 195.159.176.226 (29 Oct 2018 18:55:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2018 18:55:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: schwab@linux-m68k.org, 33014@debbugs.gnu.org To: Gemini Lasswell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 29 19:55:16 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1gHCh2-0004wn-HO for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Oct 2018 19:55:16 +0100 Original-Received: from localhost ([::1]:48312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHCj9-0007bE-2t for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Oct 2018 14:57:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHCj2-0007ax-6y for bug-gnu-emacs@gnu.org; Mon, 29 Oct 2018 14:57:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHCis-0005iv-A0 for bug-gnu-emacs@gnu.org; Mon, 29 Oct 2018 14:57:19 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47968) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHCik-0005RJ-J7 for bug-gnu-emacs@gnu.org; Mon, 29 Oct 2018 14:57:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gHCik-0007gS-IO for bug-gnu-emacs@gnu.org; Mon, 29 Oct 2018 14:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Oct 2018 18:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33014 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 33014-submit@debbugs.gnu.org id=B33014.154083938329490 (code B ref 33014); Mon, 29 Oct 2018 18:57:02 +0000 Original-Received: (at 33014) by debbugs.gnu.org; 29 Oct 2018 18:56:23 +0000 Original-Received: from localhost ([127.0.0.1]:52226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHCi6-0007fa-O1 for submit@debbugs.gnu.org; Mon, 29 Oct 2018 14:56:22 -0400 Original-Received: from alt22.smtp-out.videotron.ca ([70.80.0.73]:57932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHCi4-0007fJ-4v for 33014@debbugs.gnu.org; Mon, 29 Oct 2018 14:56:21 -0400 Original-Received: from fmsmemgm.homelinux.net ([23.233.195.134]) by Videotron with SMTP id HChvgek6oBXWOHChwgYNxQ; Mon, 29 Oct 2018 14:56:14 -0400 X-Authority-Analysis: v=2.3 cv=R4Mt5+ZX c=1 sm=1 tr=0 a=xXJ578j8WyTliCxld3/pTA==:117 a=xXJ578j8WyTliCxld3/pTA==:17 a=smKx5t2vBNcA:10 a=7DrQrguiAAAA:8 a=8WSLYSKimlQZ45fF1_wA:9 a=e6nopKXGEVcrEyEW:21 a=5SgiepY_9GTP5QRb:21 a=5p0t1moz68ydotlU2Z85:22 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 3BA35AE10E; Mon, 29 Oct 2018 14:56:11 -0400 (EDT) In-Reply-To: <83ftx3qj98.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 18 Oct 2018 20:04:03 +0300") X-CMAE-Envelope: MS4wfEv0VMatjZvT3gLG152yv+S7q2gHFAxoWAZjw3tnaXtckqG04f6klp29BgRz/9tlDYWQI18si/mxDJbGiMiiELFXqMSNURh77ox9LMFvcsxj9clcA5p4 R/axICMdBRgItKrbjA9lZ+NO3AtvZti/NdyMc9D1Ksc1LjS1ltvwsNEUhmiNimj/9IYBf8hwe3iyGPF1UMNxzvtoOalj0c8GGe0kwEVs+mWk3JLYeAS1cr8J FR1ykbPJooH2x1vFmuITOqLhdvqK8WGFlJMwrAlDJmgJUp3lZLAhg1tBDzrrY0HDXPcSjPZtFLqo50lO9Kl0tA== 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: 208.118.235.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:151785 Archived-At: >> > After thinking about this a bit, I don't really agree with the last >> > one: the compiler could indeed stop tracking 'vector', but not >> > XVECTOR (vector)->contents, and we are interested in the latter. >> If the compiler stops tracking 'vector', and the garbage collector frees >> it, doesn't that cause XVECTOR (vector)->contents to be overwritten? > Hmmm... could be. Indeed, the conservative GC doesn't try to handle "pointers into the middle of objects", so a pointer to `XVECTOR (vector)->contents` won't be sufficient to keep `vector` alive. > From: Gemini Lasswell > Date: Sun, 14 Oct 2018 12:12:04 -0700 > Subject: [PATCH] * src/eval.c (Ffuncall): Make local variable 'fun' volatile > (bug#33014) Shouldn't we do that in exec_byte_code instead (it probably doesn't matter that much in the end, but I think conceptually that would be the more correct place)? E.g. if you change your test to (defun eval-tests-33014-redefine () "Remove the Lisp reference to the byte-compiled object." (aset (symbol-function #'eval-tests-33014-func) 1 nil) (aset (symbol-function #'eval-tests-33014-func) 2 nil)) you won't get a crash but only because these `aset` will fail (bytecode objects are luckily read-only). Moving the volatile thingies to exec_byte_code should let our code work correctly against the above test even if we changed aset to allow modifying bytecode objects. Stefan