From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#34655: 26.1.92; Segfault in module with --module-assertions Date: Thu, 21 Mar 2019 21:26:25 +0100 Message-ID: References: <874l8r1t3a.fsf@tcd.ie> <8336oamu3y.fsf@gnu.org> <87h8c1cv6l.fsf@tcd.ie> <83lg1dwhse.fsf@gnu.org> <87va0h12js.fsf@tcd.ie> <835zsgw3ui.fsf@gnu.org> <87ef7486h0.fsf@tcd.ie> <83r2b4ul1c.fsf@gnu.org> <831s30upqd.fsf@gnu.org> <83o964t4de.fsf@gnu.org> <83lg18t3ar.fsf@gnu.org> <83k1gst26h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="39976"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "Basil L. Contovounesios" , 34655@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 21 21:32:56 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h74My-000AI9-85 for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Mar 2019 21:32:56 +0100 Original-Received: from localhost ([127.0.0.1]:46413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h74Mw-0006Ah-R5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Mar 2019 16:32:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h74Mh-00063Q-JH for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:32:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h74HG-0000UD-FG for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:27:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40145) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h74HG-0000Tc-3a for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h74HF-00006i-Ta for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Mar 2019 20:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34655 X-GNU-PR-Package: emacs Original-Received: via spool by 34655-submit@debbugs.gnu.org id=B34655.1553200004387 (code B ref 34655); Thu, 21 Mar 2019 20:27:01 +0000 Original-Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:26:44 +0000 Original-Received: from localhost ([127.0.0.1]:53689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Gx-00006B-UQ for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:26:44 -0400 Original-Received: from mail-oi1-f177.google.com ([209.85.167.177]:36868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Gw-00005n-BF for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:26:42 -0400 Original-Received: by mail-oi1-f177.google.com with SMTP id v84so48908oif.4 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 13:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=625FkH1nKZq6HzVmVeVuEqczj4QfqNuIgw/RykdwNL4=; b=A0E1UA89Ehy7G0vW7PIh0XQG2djdullnF+rdLoEcKdrR7q7xRnM0RDcysbHoz8/yQG dygXggxxt/jkcak9CVehKyqBjY9OzwKWrzcgaanrIHzdAmL+vcfR0WTG6UGdB3hm92Zh e/KpgniSsrR88wIjhFR1e9C4NHm3TFeNwY+BeU5UtsWOwl5gXeO0RnxTithLcFUl0mys BoKtzfxb5qlMNvd7Pj9ckc0kP82+hmnBxKhnxaQzhXb45wG5iDlEFfE906pMEEI2058N 1EISIvW/vVm8JnULVvuFbhEoCo+VV/Ni5XKBNI3HvOoxOgL0WnAjGAWq94bjrS2EvBfK ljIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=625FkH1nKZq6HzVmVeVuEqczj4QfqNuIgw/RykdwNL4=; b=n7pecDwF1rHSOXxPG6uUyoUignWwKH1czzoltEW3bXtg3j7FYr4MtFp4C1caShtxus /h4S1rU1zmnpcuTP2UjN4ls6OKpmJrwQzQi5rZrQxfEpducdOjKvmQ1Ud6t4UU8CKOou k/o9Wcx3WTCK857Oh8n2leoIqIHDROG7FpYSMPNZx38i1DuIYEMM+rLi9RupHeT0YY7Z PdjADfiSKoOY/UtkVQtoxgbG7GKeOtCrbGa2FeL/4gtJVIWscWG8iEJYUbeZpELg1Qjw vhkvj4CT1BGLck/9L33ajAR6+xDHB/RsKJL0cEnGYK4R9alwgEc+IBptXUgfXQ3LP95D ZTtQ== X-Gm-Message-State: APjAAAW/Suhh7tHUGnI8pHJpOKlcjbNMLl4U4/AF2jaBJZvqVxkpPz1A +ExSgcW4oMUhMC27Kwea4MrLdUuAIKlwpy7R42w= X-Google-Smtp-Source: APXvYqxY11tY5+8nlHbvTgzGIHJ7PQ/pobYXVErf1rudlYrEB3xpfHU9xSDIc8pJoCid8VA1eN/7KrPlmGElmFeQRSE= X-Received: by 2002:aca:d409:: with SMTP id l9mr922137oig.98.1553199996515; Thu, 21 Mar 2019 13:26:36 -0700 (PDT) In-Reply-To: <83k1gst26h.fsf@gnu.org> 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:156587 Archived-At: Am Do., 21. M=C3=A4rz 2019 um 21:14 Uhr schrieb Eli Zaretskii : > > > From: Philipp Stephani > > Date: Thu, 21 Mar 2019 21:01:43 +0100 > > Cc: Stefan Monnier , "Basil L. Contovounesios= " , 34655@debbugs.gnu.org, > > Daniel Colascione > > > > Am Do., 21. M=C3=A4rz 2019 um 20:50 Uhr schrieb Eli Zaretskii : > > > > > > > From: Philipp Stephani > > > > Date: Thu, 21 Mar 2019 20:37:24 +0100 > > > > Cc: Stefan Monnier , "Basil L. Contovoune= sios" , 34655@debbugs.gnu.org > > > > > > > > Let's go back to the known good state first, and then discuss how t= o > > > > go from there. > > > > > > I don't see why that is better than discuss first and then go to wher= e > > > we decide to go. It's not like Emacs 27 will be released any time > > > soon, so there's no rush. > > > > For one, it becomes harder and harder to revert commits the older they > > get. Also such discussions tend to turn into endless debates about the > > "perfect" solution until one side gives up, without improving > > anything. I strongly prefer fixing actual bugs that affect users in > > practice and then discussing (or not discussing) the gold-plating > > steps later. > > I also prefer fixing bugs (which is why I spent several hours looking > into Basil's crash, when no one else was replying to that bug report), > but this is a community project, so we should discuss first and act > later. Especially when controversial issues are involved. Well, as you can see, these discussions seem to lead nowhere, and both bug#34655 and bug#31238 remain unfixed. > > > > > We can't get stack marking to work, even theoretically. > > > > > > > > A module is free to do > > > > > > > > emacs_value x =3D ...; > > > > uintptr_t y =3D ((uintrptr_t) x) ^ 0x123456u; > > > > (garbage-collect) > > > > emacs_value z =3D (emacs_value) (y ^ 0x123456u); > > > > ... use z ... > > > > > > > > During the garbage collection, x isn't on the stack anywhere > > > > > > Why do you think x isn't on the stack in this case? > > > > Because the compiler reused the stack slot for something else? > > How can it? You are using the same pointer later. Assume I don't use x later, and only y is on the stack during GC. > Garbage collection > cannot happen unless you call an Emacs function, such as Ffuncall. > Calling a function means that even if the pointer to a Lisp object was > in a register, it will be put on the stack when calling Emacs. No matter whether y here is in a register or on the stack, it's not a Lisp_Value, so the GC can't find it. > > > Because the module is written in a language that doesn't use the stack > > in a way that the garbage collector expects? > > Which language is that, and how can it use the emacs-module machinery? Go, for example. It uses green threads with its own stack management and calling conventions. The GC couldn't ever find such a stack. > > > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > > > object is also somewhere on the stack, right? > > No answer? An emacs_value in the current implementation *is* a Lisp_Object cast to emacs_value. If the emacs_value is not on the stack, then there's no way to find the Lisp_Object. > > > We do something very specific with the stack: we make sure that > > Lisp_Objects are never manipulated in a way similar to the above, and > > we use the C language. > > If worse comes to worst, we can request module writers to adhere to > the same discipline. We already request them to do/not to do quite a > few extraordinary things. No we can't. Modules can contain arbitrary code and call arbitrary libraries, which we can't ever control. We need to work with everything that provides a C-compatible interface. > > > All regression tests still pass after reverting the commit. > > Didn't they also pass before? Yes, but the reproduction steps in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31238 didn't.