From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#41755: feature/native-comp (master?): temacs crash in GC during mark phase Date: Mon, 08 Jun 2020 19:05:17 +0000 Message-ID: <87tuzlwf82.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="16956"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Paul Eggert , 41755@debbugs.gnu.org, Andrea Corallo To: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 08 21:06:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jiN65-0004Jp-Qb for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jun 2020 21:06:13 +0200 Original-Received: from localhost ([::1]:56930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jiN64-0000bK-R5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jun 2020 15:06:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jiN5u-0000au-QC for bug-gnu-emacs@gnu.org; Mon, 08 Jun 2020 15:06:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46395) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jiN5u-0006Yr-H7 for bug-gnu-emacs@gnu.org; Mon, 08 Jun 2020 15:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jiN5u-0002Pl-CK for bug-gnu-emacs@gnu.org; Mon, 08 Jun 2020 15:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Jun 2020 19:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41755 X-GNU-PR-Package: emacs Original-Received: via spool by 41755-submit@debbugs.gnu.org id=B41755.15916431319236 (code B ref 41755); Mon, 08 Jun 2020 19:06:02 +0000 Original-Received: (at 41755) by debbugs.gnu.org; 8 Jun 2020 19:05:31 +0000 Original-Received: from localhost ([127.0.0.1]:57941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jiN5O-0002Ou-TX for submit@debbugs.gnu.org; Mon, 08 Jun 2020 15:05:31 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:35498) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jiN5M-0002Oh-MV for 41755@debbugs.gnu.org; Mon, 08 Jun 2020 15:05:29 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id q25so690799wmj.0 for <41755@debbugs.gnu.org>; Mon, 08 Jun 2020 12:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=OUqFwIc51QLWrdD0lFB7uJj8QWqPB2RjlbxaQ4JcRlM=; b=a/pR7lTSwU+M2m5DleJdNuCsVWTfg4V8pSYRirMjPBo1u5lMNDLf9m9cIfVHCGn3g4 eNMbQ5Za5zy9kTiLpF0t+W/i1NN56l7q9OjoLSf3DljYN1vjnrBA6IwDDDFAuouM9xfi urJXQiZRhCC99elvvU0gb65eK8uclLpWwVUHGNTq5zAAJLQ+KsLxGUWCwNknqL/ePlbq GEjUqEvQ6pxenLWFDtaQM1xAlVZ9O/2mdK37MfLus7sku8mTo2/P0y0/He12k2KFgd3r /lzoIZdH/5i6RzS5cPhUhHdfd3YUfDXkCgQ0URULCufud8db+/iBE7fcW8abfAV2/c70 9BAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=OUqFwIc51QLWrdD0lFB7uJj8QWqPB2RjlbxaQ4JcRlM=; b=purcWS32kkpJXd0U5qDd0jkvjg7zSriNaK5K8dkw9cWpCmKZi2a1y8dtxdoyktm9O6 uhLm4c2/ESRvA8bfPL6xjNqAo0vq9mT/LiIqKTiU5epXWf7/PSw3ohz+RzA3dhOeRTNf b3QZjiajOL9rGezqBpxwhGgaGbfQjqPs6xkplHVJ98hSDR5XOdFVuARmhpncT4+rHm74 CsiMqwQjTursJqKtB3nnFjps00jMfjWsKekyTDamv+e/IfMMJcSCsiogi6lY3WoCF881 ff5HyxQs8IkAYZcIxDCnHaXMx8eTSc/wJ2LhOzsHOtzdGwHlCvCjMSCx7Jc9D8L7zXJW XpQA== X-Gm-Message-State: AOAM533w911FbyuRld8WKi7io5JQ0FSmrzF+0lLj2QnKQ9SVEhdvb1Zp Q6sQotT0XGHiDfFl6D0CzyM= X-Google-Smtp-Source: ABdhPJxUWlpB0pLbAij3rxmu6BmHrVCWFuZ9JI/QEaP1TN46zrZcW8LvzZOn+JuRv5aOWuuONrgunQ== X-Received: by 2002:a1c:7e52:: with SMTP id z79mr179075wmc.104.1591643122823; Mon, 08 Jun 2020 12:05:22 -0700 (PDT) Original-Received: from chametz ([185.220.101.214]) by smtp.gmail.com with ESMTPSA id n19sm418371wmi.33.2020.06.08.12.05.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 12:05:22 -0700 (PDT) In-Reply-To: ("Nicolas =?UTF-8?Q?B=C3=A9rtolo?="'s message of "Mon, 8 Jun 2020 15:51:14 -0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181747 Archived-At: Nicolas B=C3=A9rtolo writes: >> I'm wondering what we could do to make such bugs easier to find... > > We could add a canary to stack based strings and conses. Then while > marking if we > come across a stack based string or cons we check that the canary is > intact. If > it is not, then we can be sure that the memory has been written over. I believe we should never be marking stack-based objects. If we do that's a GC bug. Code like AUTO_STRING (s, "foo"); Lisp_Object c =3D Fcons (s, s); garbage_collect (); ... Fsetcar (c, Qnil); Fsetcdr (c, Qnil); shouldn't work. I hope it doesn't :-) (With GC_CHECK_MARKED_OBJECTS, it should abort; without, it would leave the mark bit of s set, so the "..." code would presumably crash). > Something like this: > > struct Stack_String > { > struct Lisp_String string; > uint64_t canary =3D 0x12341234; > }; > >> Would GC_CHECK_MARKED_OBJECTS have caught this? > > As far as I can see, during a GC we can't know if a stack-based string > is still alive. But we can know whether a string is stack-based or not; if it is, we shouldn't be marking it, so we can abort in that case...