From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#34655: 26.1.92; Segfault in module with --module-assertions Date: Thu, 21 Mar 2019 22:44:58 +0200 Message-ID: <83ftrgt0s5.fsf@gnu.org> 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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="158922"; mail-complaints-to="usenet@blaine.gmane.org" Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, monnier@iro.umontreal.ca To: Philipp Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 21 22:00:25 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 1h74nX-000f60-B7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Mar 2019 22:00:23 +0100 Original-Received: from localhost ([127.0.0.1]:46790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h74nW-0001hJ-9Y for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Mar 2019 17:00:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h74gt-0004eD-KL for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:53:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h74Ze-00006F-Ik for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40165) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h74Ze-00005i-7F for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h74Zd-0003cK-Vg for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 16:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Mar 2019 20:46: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.155320111310713 (code B ref 34655); Thu, 21 Mar 2019 20:46:01 +0000 Original-Received: (at 34655) by debbugs.gnu.org; 21 Mar 2019 20:45:13 +0000 Original-Received: from localhost ([127.0.0.1]:53709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Yq-0002m5-8W for submit@debbugs.gnu.org; Thu, 21 Mar 2019 16:45:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:32800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h74Ym-0002dg-Sb for 34655@debbugs.gnu.org; Thu, 21 Mar 2019 16:45:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h74Yd-0007DB-M4; Thu, 21 Mar 2019 16:45:00 -0400 Original-Received: from [176.228.60.248] (port=3470 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h74Yd-0006dp-54; Thu, 21 Mar 2019 16:44:59 -0400 In-reply-to: (message from Philipp Stephani on Thu, 21 Mar 2019 21:26:25 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:156590 Archived-At: > From: Philipp Stephani > Date: Thu, 21 Mar 2019 21:26:25 +0100 > Cc: Stefan Monnier , "Basil L. Contovounesios" , 34655@debbugs.gnu.org, > Daniel Colascione > > > 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 have been talking about this just a few minutes, so please don't exaggerate. And bug#34655 could be fixed days ago, it isn't yet because I wanted to hear your opinion, and you asked me to hold off the changes. > > > > 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. If you don't use x, it can be GC'ed. > > 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. But x is. And there's the original Lisp object too, somewhere on the stack. > > > 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. So you are saying that Emacs modules cannot be written in Go? > > > > 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. Under module-assertions, it's a pointer to a (copy of a) Lisp object. > > 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. Emacs modules are written to work with Emacs, so surely we can request them to observe certain rules, especially if they don't want to crash Emacs.