From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.bugs Subject: bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function Date: Fri, 19 Oct 2018 13:05:19 -0700 Message-ID: <878t2tbt34.fsf@runbox.com> 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> <83in21snha.fsf@gnu.org> <87woqebx9v.fsf@runbox.com> <83va5ypbpo.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: blaine.gmane.org 1539979448 15822 195.159.176.226 (19 Oct 2018 20:04:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Oct 2018 20:04:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: 33014@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 19 22:04:04 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 1gDb07-00041x-Nz for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2018 22:04:03 +0200 Original-Received: from localhost ([::1]:52486 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDb2E-0002dM-6Y for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Oct 2018 16:06:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gDb27-0002d5-U2 for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 16:06:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gDb23-0006oj-S0 for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 16:06:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55544) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gDb23-0006o4-NM for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 16:06:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gDb23-0002O9-BQ for bug-gnu-emacs@gnu.org; Fri, 19 Oct 2018 16:06:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Oct 2018 20:06:03 +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: Original-Received: via spool by 33014-submit@debbugs.gnu.org id=B33014.15399795269133 (code B ref 33014); Fri, 19 Oct 2018 20:06:03 +0000 Original-Received: (at 33014) by debbugs.gnu.org; 19 Oct 2018 20:05:26 +0000 Original-Received: from localhost ([127.0.0.1]:59802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDb1S-0002NE-1P for submit@debbugs.gnu.org; Fri, 19 Oct 2018 16:05:26 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:56636) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gDb1Q-0002N6-D6 for 33014@debbugs.gnu.org; Fri, 19 Oct 2018 16:05:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=hebFdLbSJJ1ZzvEZ/x9LbH4fLvpjgaUMPRxWc7yZIv8=; b=b8/8jvEhMvh9pcDrOkYk3AWbX4 ZCVeM3L0TfCt+0RV4zXRO0pWvEhw1+i2x1iKmtQsZ13i38+AJWo/+oL+Z9V12fFaF6GeXMGaO+/l3 +6MTAEB3V34izGZg5wqQ5L08fPSs8T4qt5VHj+aVPMUjZaOzokSexfvnefsDRty1xe2oViXnWqn/w HGuhBlDhfigqwPDCuRhg0S8AtWUxh8HytBnLuwUMxAQzUDLpJKor/2ZK1uORPTIhN6l/N3L/t93aQ COg6BYotbEkzWPQ660e7T/6EN6mFbFQn5Vcv2N9xypRvcfRqbpFUkqYqzjRt6VFBuLxwg74/f7hSd DMKuqpjQ==; Original-Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1gDb1P-00036u-6m; Fri, 19 Oct 2018 22:05:23 +0200 Original-Received: by mailfront11.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1gDb1N-0004rZ-02; Fri, 19 Oct 2018 22:05:21 +0200 In-Reply-To: <83va5ypbpo.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 Oct 2018 11:44:35 +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: 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:151452 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> > Anyway, are you saying that stack marking doesn't work in optimized >> > code? We've been using this technique for the last 17 years without >> > problems; why would the fact that we have more than one thread change >> > that? The same arguments you submit are valid for a single-threaded >> > Emacs, right? >> >> Apparently so. I set up a single-threaded situation where I could >> redefine a function while exec_byte_code was running it, and got a >> segfault. I've gained some insights from debugging this version of the >> bug which I will put into a separate email. > > If this is the case, then I think we should protect the definition of > a running function from GC, in some way, either by making sure it is > referenced by some stack-based Lisp object, even in heavily optimized > code (e.g., by using 'volatile' qualifiers); or by some other method > that will ensure that definition is marked and not swept. Maybe code optimizers have improved over the last 17 years? I have patched Emacs with a 'volatile' on the definition of 'fun' in Ffuncall, and so far haven't managed to reproduce the bug with it: --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=0001-src-eval.c-Ffuncall-Make-local-variable-fun-volatile.patch >From a1fc2dfd392e0ba8754159d855da231a56ca275b Mon Sep 17 00:00:00 2001 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) --- src/eval.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/eval.c b/src/eval.c index 5e25caaa84..75b30f9c7d 100644 --- a/src/eval.c +++ b/src/eval.c @@ -2817,8 +2817,8 @@ Thus, (funcall \\='cons \\='x \\='y) returns (x . y). usage: (funcall FUNCTION &rest ARGUMENTS) */) (ptrdiff_t nargs, Lisp_Object *args) { - Lisp_Object fun, original_fun; - Lisp_Object funcar; + Lisp_Object volatile fun; + Lisp_Object original_fun, funcar; ptrdiff_t numargs = nargs - 1; Lisp_Object val; ptrdiff_t count; -- 2.16.4 --=-=-= Content-Type: text/plain I'll go back now to working on my benchmarking project which I hope someday will make it easy to see if that 'volatile' causes measurable harm to performance. I'll also keep using 'eval-region' and 'eval-buffer' while I have threads running byte-compiled functions which get redefined by doing that, and report back here if I encounter this bug again. --=-=-=--