From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#40661: Crash in regex search during redisplay Date: Mon, 20 Apr 2020 22:06:59 +0300 Message-ID: <83v9luf030.fsf@gnu.org> References: <83ftd3e92z.fsf@gnu.org> <83d087e6gj.fsf@gnu.org> <421071D0-6D75-4442-AC4B-D091B573B49C@dancol.org> <838siucq7b.fsf@gnu.org> <83tv1iaz7g.fsf@gnu.org> <834kthatwj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="78851"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 40661@debbugs.gnu.org To: Richard Copley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 20 21:08: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 1jQbmA-000KPV-Qi for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Apr 2020 21:08:14 +0200 Original-Received: from localhost ([::1]:41042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQbm9-0005Wg-JD for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Apr 2020 15:08:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51256 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQbm0-0005Wa-CH for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 15:08:04 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQbly-0005iF-LC for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 15:08:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36870) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQbly-0005fj-3R for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 15:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jQblx-0003iC-UB for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 15:08: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: Mon, 20 Apr 2020 19:08: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.158740964214224 (code B ref 40661); Mon, 20 Apr 2020 19:08:01 +0000 Original-Received: (at 40661) by debbugs.gnu.org; 20 Apr 2020 19:07:22 +0000 Original-Received: from localhost ([127.0.0.1]:48416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQblE-0003hG-1i for submit@debbugs.gnu.org; Mon, 20 Apr 2020 15:07:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48172 helo=eggs1p.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQblC-0003h1-49 for 40661@debbugs.gnu.org; Mon, 20 Apr 2020 15:07:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53514) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQbl5-0004Xt-Qp; Mon, 20 Apr 2020 15:07:08 -0400 Original-Received: from [176.228.60.248] (port=3804 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQbl4-0005fr-Gz; Mon, 20 Apr 2020 15:07:07 -0400 In-Reply-To: (message from Richard Copley on Mon, 20 Apr 2020 19:30:29 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:178727 Archived-At: > From: Richard Copley > Date: Mon, 20 Apr 2020 19:30:29 +0100 > Cc: Stefan Monnier , Daniel Colascione , 40661@debbugs.gnu.org > > I have a little worry about the situation where the procedure of doing > a "decoding" entails a regexp buffer search. (I can't make out whether > or not "decoding" means executing arbitrary Lisp code.) This can happen if the coding-system has a post-read-conversion attribute, yes. > Is it possible, with your patch, that we might re-enable buffer > shrinking sooner than desirable? I don't think I understand the scenario you have in mind. If decoding calls regexp search, then we inhibit shrinking inside the regex routines, not outside of them. Which code will re-enable shrinking before the regex routines return? > (This is reiterating a worry you yourself mentioned earlier, "I'm > not sure we want to conflate these two purposes".) coding.c uses this flag only while it runs purely C code. Lisp cannot run at that point. If a coding-system has a post-read-conversion, it will run only after the C decoder finishes. > In the comment, you mention relocation as well as shrinking. It's the relocation that causes the crash, because following the relocation we unmap a portion of the process memory, where previously we had buffer text, from the process's address space. Shrinking of the gap is what triggers the relocation (when the original gap was very large). > Does it make sense to combine this new guard with the existing > freeze_buffer_relocation in some way? I thought about that, but decided against it, for two reasons. First, freeze_buffer_relocation should at some point go away: it is not a no-op only in an Emacs that uses ralloc.c, which currently only the MS-DOS build does, AFAIK. And second, it freezes relocation at a higher level than needed, above the re_match_2_internal function which is the only one that can call Lisp.