From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#40661: Crash in regex search during redisplay Date: Fri, 17 Apr 2020 07:01:04 -0700 Message-ID: References: <83ftd3e92z.fsf@gnu.org> <83d087e6gj.fsf@gnu.org> <421071D0-6D75-4442-AC4B-D091B573B49C@dancol.org> <838siucq7b.fsf@gnu.org> <834kticj33.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="48388"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.23.0-1556 (build: 102300002) Cc: monnier@iro.umontreal.ca, 40661@debbugs.gnu.org To: Eli Zaretskii , Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 17 16:02:37 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 1jPRZk-000CSt-RU for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Apr 2020 16:02:37 +0200 Original-Received: from localhost ([::1]:47714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPRZj-0003EP-Kl for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Apr 2020 10:02:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40652) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPRZE-0003DZ-5W for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 10:02:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jPRZB-0005nv-UR for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 10:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58087) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jPRZB-0005nr-OX for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 10:02:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jPRZB-0007ER-Mw for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 10:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Apr 2020 14:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40661 X-GNU-PR-Package: emacs Original-Received: via spool by 40661-submit@debbugs.gnu.org id=B40661.158713207227729 (code B ref 40661); Fri, 17 Apr 2020 14:02:01 +0000 Original-Received: (at 40661) by debbugs.gnu.org; 17 Apr 2020 14:01:12 +0000 Original-Received: from localhost ([127.0.0.1]:41400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPRYO-0007DB-3G for submit@debbugs.gnu.org; Fri, 17 Apr 2020 10:01:12 -0400 Original-Received: from dancol.org ([96.126.100.184]:36466) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPRYM-0007D2-2C for 40661@debbugs.gnu.org; Fri, 17 Apr 2020 10:01:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Message-Id:Content-Transfer-Encoding:Content-Type:MIME-Version: Subject:References:In-Reply-To:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OKpH/RfPgn4cyvogknLD2Q0JkjnbH1dMJLPthmLvA1Y=; b=mLufx+EVDgmMZTYBZgP+8QjanO wLYln8wCz4NBuqxe5Lts+pOCYi8C9/Z3JQYHdvVEMt7FHtA++Ykc+k+5v3DFWQEfFBwSsdpE/j+pk /QJttguGOe0jrqDIXOuXwQkAgAE4M9InjhaAhb7NL/Pl0iDGM5zCabKiE3uyWIfJw8oHkK6tbYj8u 2Wugm7SHrJdSLRbYt3xZa5Vdi6z/LVAdi77cjXilduNSq1gx9S6/MOAkbLhRv/oY+fzhXWJ9joT00 shy5Yk1GClKSqX3tab+52F/HiTA7WxILV9BUk3OIQYA5ioi+UWtEgDYxfPyzZ8uywLhkLhOI5f+dD x/FN1qcg==; Original-Received: from [172.92.145.124] (helo=[192.168.86.155]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jPRYH-0006s5-KP; Fri, 17 Apr 2020 07:01:05 -0700 In-Reply-To: <834kticj33.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178514 Archived-At: On April 17, 2020 6:56:00 AM Eli Zaretskii wrote: >> Date: Fri, 17 Apr 2020 14:22:00 +0300 >> From: Eli Zaretskii >> Cc: 40661@debbugs.gnu.org >> >> Obviously, we cannot allow GC to run while regex routines do their >> work, because they are passed C pointers to buffer text. The question >> is, where to disable GC? We could do it inside >> update_syntax_table_forward, but UPDATE_SYNTAX_TABLE_FORWARD is called >> from many places that evidently have no problems with GC. So my >> suggestion would be to disable GC inside re_match_2_internal instead. > > Alternatively, we could set the buffer's inhibit_shrinking flag while > in re_match_2_internal. Although that flag was introduced for a > different purpose: for when we have stuff inside the gap that we don't > want to lose. The name of the flag notwithstanding, I'm not sure we > want to conflate these two purposes. But maybe it's better than > preventing the GC entirely. I think I'd prefer this approach to inhibiting GC entirely. I can imagine code allocating enough garbage that we really want to get rid of it, and inhibiting shrinking is more conservative.