From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#40661: Crash in regex search during redisplay Date: Mon, 20 Apr 2020 19:30:29 +0100 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="47147"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , 40661@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 20 20:32:11 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 1jQbDG-000CAQ-OS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Apr 2020 20:32:10 +0200 Original-Received: from localhost ([::1]:40546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQbDF-0007Yh-Ii for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Apr 2020 14:32:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43834 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQbD9-0007YP-0q for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 14:32:03 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQbD8-0001L2-GM for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 14:32:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36852) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQbD8-0001Jp-3E for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 14:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jQbD8-0002md-0l for bug-gnu-emacs@gnu.org; Mon, 20 Apr 2020 14:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2020 18:32: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.158740746610594 (code B ref 40661); Mon, 20 Apr 2020 18:32:01 +0000 Original-Received: (at 40661) by debbugs.gnu.org; 20 Apr 2020 18:31:06 +0000 Original-Received: from localhost ([127.0.0.1]:48390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQbCD-0002ko-Tz for submit@debbugs.gnu.org; Mon, 20 Apr 2020 14:31:06 -0400 Original-Received: from mail-ot1-f49.google.com ([209.85.210.49]:41461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jQbCA-0002kI-8j for 40661@debbugs.gnu.org; Mon, 20 Apr 2020 14:31:04 -0400 Original-Received: by mail-ot1-f49.google.com with SMTP id c3so8991059otp.8 for <40661@debbugs.gnu.org>; Mon, 20 Apr 2020 11:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rOcvy/DNVWgjEGW0fXTQl1rjy4fXu5JeZjl9KMoPxrU=; b=mv2ple8jQw7rfrGuOfbLQQGiyXj5cdTrQSkCvwJ58069JThKRpRLguj2wb2qqsEyvS iKcpQKy2PNff+Wiv200Bc+haqqXQPZxmpSK6V5qwAgBgoZ47Ohjy4tRwHPXVXbsc/PFl K0sbNS0CuIwOnJYF7930aFqCv4eOma03+C6HcONV8gapLy3YOSQgmJUbbdM7PsWoRH9P 7lX5JSBJgd1K9JHzjLFalBMBUGbybCUnVO6yQXuqUHFo2J5hB7158EoQ0EriZD7PEBWH tFNhuW5gEZEjGpNpIiTI56ztyxPAMv630xFl2YRrT23AbCVm1HY10wxAUBM6LffnrsF6 PICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rOcvy/DNVWgjEGW0fXTQl1rjy4fXu5JeZjl9KMoPxrU=; b=RN6MumwCfHRZPAObattRt2Ua17L1dLV5z5AS0eTEO2JTcfRuawLF0urreqsvuBw61b Tc1A/9cTqOIBL40BWaxPx0KH76BU8+J017mzMIKTi7UUKloksOGZps59kznG705wdUgy G1HMX2YzgrDcgg7VeDwxBcJJqCORRgFbWwLRliZxLCGOklnVhVC+4+6cekjgSyUAKMmT +/K8MeDnCdo7kH4f5tyg3Eo5jVzE1wOoF4MnWte4gZnrcwafqxcMJ+Lg11YoHpwZdhEH YGrYAslyv+LOcJ6ZQ+psLuXXyD0Wx+BYJ/o8EqUlsyMY5EuG68Bfuvm7uajVt0JuxszA npGg== X-Gm-Message-State: AGi0PuZZVkLgnOqmSd/IPZbp/PWPmaHcMQO3kZgDgwTyxN6MOky2yEyA y9mqlZAEcEXxiSakFmVYXVo7wix8Igf6gzYk02Q= X-Google-Smtp-Source: APiQypK2dc9dcDTIGmMz0vioupskp88EUwaQQOT4KxVk5znbWvmzkkLxgSD4LPaEwzIppE50yTGcgu8RQFURoMDNaMU= X-Received: by 2002:a9d:1441:: with SMTP id h59mr3790673oth.192.1587407456498; Mon, 20 Apr 2020 11:30:56 -0700 (PDT) In-Reply-To: <834kthatwj.fsf@gnu.org> 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:178726 Archived-At: On Sat, 18 Apr 2020 at 12:57, Eli Zaretskii wrote: > OK, thank you and Daniel for the feedback, and thanks to Richard for > finding this bug in the first place. > > I installed a fix on the emacs-27 branch, it avoids the crashes in the > recipe posted by Richard. Please eyeball the fix, in case I made some > stupid mistake (my environment is rather noisy today, so I trust > myself even less than I usually do). There are a couple of points about the patch that aren't clear to me. I think you have probably thought them already. I hope you don't mind me asking for clarification. 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.) Is it possible, with your patch, that we might re-enable buffer shrinking sooner than desirable? (This is reiterating a worry you yourself mentioned earlier, "I'm not sure we want to conflate these two purposes".) In the comment, you mention relocation as well as shrinking. Does it make sense to combine this new guard with the existing freeze_buffer_relocation in some way?