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: Fri, 22 Mar 2019 11:17:56 +0300 Message-ID: <83sgvfs4p7.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> <54c0397230795ccc3701339de617d887.squirrel@dancol.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="10197"; mail-complaints-to="usenet@blaine.gmane.org" Cc: contovob@tcd.ie, 34655@debbugs.gnu.org, p.stephani2@gmail.com, monnier@iro.umontreal.ca To: "Daniel Colascione" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 22 09:27:27 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 1h7FWQ-0002XO-3U for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Mar 2019 09:27:26 +0100 Original-Received: from localhost ([127.0.0.1]:53813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7FWN-0006WB-82 for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Mar 2019 04:27:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7FUf-0004xg-0N for bug-gnu-emacs@gnu.org; Fri, 22 Mar 2019 04:25:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7FOI-0002KU-8g for bug-gnu-emacs@gnu.org; Fri, 22 Mar 2019 04:19:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40425) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h7FOH-0002KM-Sf for bug-gnu-emacs@gnu.org; Fri, 22 Mar 2019 04:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h7FOH-00076i-NB for bug-gnu-emacs@gnu.org; Fri, 22 Mar 2019 04:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Mar 2019 08:19: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.155324268327247 (code B ref 34655); Fri, 22 Mar 2019 08:19:01 +0000 Original-Received: (at 34655) by debbugs.gnu.org; 22 Mar 2019 08:18:03 +0000 Original-Received: from localhost ([127.0.0.1]:53969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7FNL-00075P-8h for submit@debbugs.gnu.org; Fri, 22 Mar 2019 04:18:03 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7FNI-00074v-Q6 for 34655@debbugs.gnu.org; Fri, 22 Mar 2019 04:18:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7FNC-0000nJ-T8; Fri, 22 Mar 2019 04:17:55 -0400 Original-Received: from [176.228.60.248] (port=2390 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7FNC-0001o9-DJ; Fri, 22 Mar 2019 04:17:54 -0400 In-reply-to: <54c0397230795ccc3701339de617d887.squirrel@dancol.org> 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:156603 Archived-At: > Date: Thu, 21 Mar 2019 13:48:28 -0700 > From: "Daniel Colascione" > Cc: "Eli Zaretskii" , > "Stefan Monnier" , > "Basil L. Contovounesios" , > 34655@debbugs.gnu.org, > "Daniel Colascione" > > > 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. > > Modules can contain arbitrary code, but they don't have to do arbitrary > things with that code. Right now, the contract between modules and Emacs > is something like "any value that, I, Emacs, can't find on an > Emacs-findable thread is fair game for memory reclaimation." In practice, > that works okay most of the time, but if we have to deal with environments > that can't guarantee that Emacs values remain on the C stack, we can > extend the contract with something like "I, module, am handing you, Emacs, > an array of emacs_values, and in addition to my stack, you should check > this array before considering a value dead" --- that is, we could just > provide a way for a module to associate a bunch of additional GC roots > with a given context. Then something like Go could stick any temporary > Emacs values in this array. > > Or we could just have these environments create permanent references. OK, thanks. What are your opinions regarding usability of stack marking for emacs_value variables used by modules?