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.