unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Copley <rcopley@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 40661@debbugs.gnu.org
Subject: bug#40661: Crash in regex search during redisplay
Date: Mon, 20 Apr 2020 19:30:29 +0100	[thread overview]
Message-ID: <CAPM58ojojj8mFGSr-aFa05+n2DrZi4HE2gg7Gj8Hbd7RSqU0ug@mail.gmail.com> (raw)
In-Reply-To: <834kthatwj.fsf@gnu.org>

On Sat, 18 Apr 2020 at 12:57, Eli Zaretskii <eliz@gnu.org> 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?





  reply	other threads:[~2020-04-20 18:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-16 14:35 bug#40661: Crash in regex search during redisplay Richard Copley
2020-04-16 15:36 ` Eli Zaretskii
2020-04-16 16:33   ` Eli Zaretskii
2020-04-16 16:42     ` Daniel Colascione
2020-04-16 16:56       ` Richard Copley
2020-04-16 17:24         ` Daniel Colascione
2020-04-16 19:35           ` Richard Copley
2020-04-17 11:22             ` Eli Zaretskii
2020-04-17 13:55               ` Eli Zaretskii
2020-04-17 14:01                 ` Daniel Colascione
2020-04-17 15:28               ` Stefan Monnier
2020-04-17 15:50                 ` Eli Zaretskii
2020-04-17 16:00                   ` Stefan Monnier
2020-04-18 11:57                     ` Eli Zaretskii
2020-04-20 18:30                       ` Richard Copley [this message]
2020-04-20 19:06                         ` Eli Zaretskii
2020-04-20 23:04                           ` Richard Copley
2020-09-30  3:49                             ` Lars Ingebrigtsen
2020-04-16 16:57       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPM58ojojj8mFGSr-aFa05+n2DrZi4HE2gg7Gj8Hbd7RSqU0ug@mail.gmail.com \
    --to=rcopley@gmail.com \
    --cc=40661@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).