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:01:43 +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> 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="224924"; 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:13:24 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 1h7444-000wOx-3F for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Mar 2019 21:13:24 +0100 Original-Received: from localhost ([127.0.0.1]:46213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7443-0008Px-0q for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Mar 2019 16:13:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h742v-0007R4-Dj for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:12:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h73u2-0006yO-Rj for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:03:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40121) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h73u2-0006xX-H1 for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h73u2-0007xD-Bs for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:03:02 -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:03:02 +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.155319852430500 (code B ref 34655); Thu, 21 Mar 2019 20:03:02 +0000 Original-Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:02:04 +0000 Original-Received: from localhost ([127.0.0.1]:53662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73t6-0007vs-3K for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:02:04 -0400 Original-Received: from mail-ot1-f68.google.com ([209.85.210.68]:46900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73t3-0007vL-Us for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:02:02 -0400 Original-Received: by mail-ot1-f68.google.com with SMTP id c18so6513388otl.13 for <34655@debbugs.gnu.org>; Thu, 21 Mar 2019 13:02:01 -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=KfEqZLbYjgz6P+SwUjqo0vChHeEcQi2hKFNR1Un8zZo=; b=ScHc7+rUcCcjRusM89t68OCEhF9QCyDVyQv4fA/th+6XqX9QFBSGm0k52xcRcbnXqV s4XNqh1Uf5P6sbeYKiCmkyy52gk+OzywHMCnkHmxe4p51f+QLoJZxD5zorZbXt8rhM+/ lZR5jC+DL0UGpc9ZmODrhuy9erS0vybxRksUeHPu8woBgyNJWWw+hs3Rz88KYkMCaOEx 0laFqTyaMh0pS90ZDT3GNBBcYNIe99OewTKlOWyuyaW3wrCTDUPRESe7Xt/Hp2ua5MXT gaRpV5btGbNPsgyky3wi7cFLX3+Ndtd50jNzbXDULwka4Pcr2haNhlPtRoQbKJRMX+Lf xHXw== 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=KfEqZLbYjgz6P+SwUjqo0vChHeEcQi2hKFNR1Un8zZo=; b=Y+pqY3RG1I+oQ1pv4O6KO9/MljF5JP0H9eqn1d73RfXUly2FaMFArvZfVs5P2NoML5 6h0EGR3g1hIrK0VMgFW5memlWqCXoBAZQFMwWdiEjOrg9M5BXoB52NyhHCy3S39/KbSJ rNJosAtZJE4Klkizbi/+Fx782NLNUxWKY2CJevTmIOttNgaoFMzDtY0QLK7PTwEERRG7 ty02YIwjxwNd1rkUN2wOScKbf8ux1VaV/+sZHmM/nIgbSPG1x3DziOZO1fhSzcmiaeiu je9yyoYfszf3KPUxaM95BPLIGsVdWKVS0+YWoL3XFnE/s0aZsqtT5c2X2lMWfFwOGqJb pGqQ== X-Gm-Message-State: APjAAAXA7+rFYRs4SIKehX+WULxM7CfZk+klgNZ0RTTmWxt1ADSWYBfy Cbi9WqRq7J9eFa4np7Xbd8HMJ9tciRC8Dj2dc3A= X-Google-Smtp-Source: APXvYqxaNp1/pypgUVEGZztEGp+UJeYPDgq9TxUL0cVMnzzDs7gaaCkeSN5HoYEBtP4VaCbonhAb7FSgIxcHemFP1ZM= X-Received: by 2002:a9d:62c8:: with SMTP id z8mr3924886otk.144.1553198514773; Thu, 21 Mar 2019 13:01:54 -0700 (PDT) In-Reply-To: <83lg18t3ar.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:156584 Archived-At: 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. Contovounesios= " , 34655@debbugs.gnu.org > > > > Let's go back to the known good state first, and then discuss how to > > go from there. > > I don't see why that is better than discuss first and then go to where > 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. > > > 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? Because the module is written in a language that doesn't use the stack in a way that the garbage collector expects? There's no reason to assume modules have any form of C-compatible stack layout. > > Moreover, emacs_value is actually a pointer to a Lisp object, so this > object is also somewhere on the stack, right? > > > emacs_value x =3D ...; > > emacs_value *y =3D malloc (sizeof emacs_value); > > *y =3D x; > > ... stop using x... > > (garbage-collect) > > ...use *y ... > > > > Again, during garbage collection x is no longer on the stack. > > Why do you think it isn't on the stack? Same as above. > > > We can only use stack scanning in Emacs because we control the Emacs > > source code > > Actually, we do nothing special about stack-based values in our > sources, except avoiding undefined behavior. (Stack scanning is undefined behavior, but that's not the point.) 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. > > > > OK, but I think Stefan's opinion is not less important. > > > > I value his opinion, but again: let's make the thing work first, and > > then discuss options. > > Fixing one bug doesn't necessarily mean things now "work"; there's > always one more bug. That might be theoretically true, but shouldn't impact decisions until that bug is actually found. All regression tests still pass after reverting the commit.