From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely Date: Wed, 14 Sep 2022 18:57:23 +0200 Message-ID: References: <87pmfx6h7y.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000081b7b105e8a60690" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39671"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57804@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 14 19:22:37 2022 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 1oYW5s-000A8Z-Ps for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Sep 2022 19:22:36 +0200 Original-Received: from localhost ([::1]:59506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYW5r-0001DK-Pc for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Sep 2022 13:22:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYVi7-0006f6-9b for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 12:58:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38992) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYVi7-0003pZ-1s for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 12:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYVi6-0005w1-IX for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 12:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Sep 2022 16:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57804 X-GNU-PR-Package: emacs Original-Received: via spool by 57804-submit@debbugs.gnu.org id=B57804.166317466322788 (code B ref 57804); Wed, 14 Sep 2022 16:58:02 +0000 Original-Received: (at 57804) by debbugs.gnu.org; 14 Sep 2022 16:57:43 +0000 Original-Received: from localhost ([127.0.0.1]:55924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVhn-0005vU-1Z for submit@debbugs.gnu.org; Wed, 14 Sep 2022 12:57:43 -0400 Original-Received: from mail-ej1-f45.google.com ([209.85.218.45]:35385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYVhk-0005vG-UM for 57804@debbugs.gnu.org; Wed, 14 Sep 2022 12:57:41 -0400 Original-Received: by mail-ej1-f45.google.com with SMTP id go34so36193463ejc.2 for <57804@debbugs.gnu.org>; Wed, 14 Sep 2022 09:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=JuH4c7fIiOxw7wRV+uD1nilHBjXlhXYllZFNsif2i1s=; b=AB6yTBjBz8XxuXDyAnc1v0jRQ9fzHFxMwnSKM4Piuj9dhmaEZ1hEjRIKPH0R/pvtgi 5Bsq+PKQDyufg7DsyIr2V60jVEqbUGIsSLu9Wx575U7c4vtKlwY5YxXgQsema3qgAKRJ jUrp8RFnVD4sjmry7rLtncpp+mw7A61lBU4htoowM9yxb+cWey6jBv3Ynd0sxb3lNuGb E8kdhjsH4Z6KlqLmHQFLisG7z2osFOr673oSl57reqdoJis+5mR9Fa51d0yd3C1Fja3/ VEa1Q2bdseTqjebZXq+3c8TwbV8v08rNpAlUu04wh2xx0qdUiruwT1np6AMb7KtFPb8r 8vog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=JuH4c7fIiOxw7wRV+uD1nilHBjXlhXYllZFNsif2i1s=; b=MYPhmpepg5sysVsDpK+sWCZ1cCdAmYa3HQ+HV7MxwtlQXbEYZPCN0x7ZXB1hAIGij5 4J/+Po6KzeX7jDzhJXkFqk/khYPxSOCRhOnB9wMduUY1t+A8O2flmT2bKoiDsKY/v5lT PSpRW6a95ZD1Mrhbng6szcn/c0WHcvw/TaGLhNpb8H9QzExqxPT/nPt8H96S0vwPxGVm YC10p7iPfm/xgJHJ6Z1JYuhi7WpFxVs6tX6kKP96sF7nF1/sTxSZU2vDvGpKyUO39c+J OHnJ5NPPQLUY3Qb1fJxFxLnqHEHITbAv5VevXv3DUFKbHHEDIFKeJHYkXVkCVwJIxu+w uVNw== X-Gm-Message-State: ACgBeo134baiP6pIdn9KMGEcyz3C13u+Xf20ytULs6LY+EAmzIAaPBwT 6QO6gJzNoNdEtdcbtNC+MWJ8IUF5cqSaM259KA== X-Google-Smtp-Source: AA6agR5Y1+5Ofx6MM9Vj1JGStxKk0m9uyvGFCmGXulUXJS3nwm288mhUWqMwWQgXLSeWNj21tssUVrYKlegqFDLJbSs= X-Received: by 2002:a17:907:7b95:b0:731:113a:d7a2 with SMTP id ne21-20020a1709077b9500b00731113ad7a2mr25322640ejc.377.1663174654931; Wed, 14 Sep 2022 09:57:34 -0700 (PDT) In-Reply-To: <87pmfx6h7y.fsf@gnus.org> 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:242488 Archived-At: --00000000000081b7b105e8a60690 Content-Type: text/plain; charset="UTF-8" > We've previously discussed making a certain key sequence disable font > locking in a buffer -- or blacklist the particular functions that's > inflooping somehow. I think from a user point of view a _special_ sequence is a bad idea, as most users won't know about it. Blacklisting I'd say is even worse, because that would mean a user first have to expirience a hang of Emacs, find out _which_ function caused it (remember, that Emacs is either unresponsive or is killed by now), find out that it is possible to blacklist it and do it. Way too much to expect from a user. Besides, a function may not be outright malicious, only buggy in certain corner-cases, so it would be much nicer to be able to force-abort it when that happens. E.g. in my case this happened in Logview mode, because it expected `widen' to, well, widen, but Emacs `master' introduced half-cooked narrowed locking that broke that expectation and then Logview fell into an infinite loop, because the buffer was not in the state the mode expected it to be. > For instance, if the user hits `C-g' three times (and Emacs doesn't idle > in between), then we disable font-lock in that buffer. That sounds much better. I know that `C-g' is what to press when Emacs is stuck. > There's also `max-redisplay-ticks' -- but I'm not sure that would have > helped here? If I add `(setf max-redisplay-ticks 100)' right after entering `buggy-mode', it seems to have some effect, but not exactly what I'd hope on. I suggest you try and see for yourself, hard to describe them. Paul --00000000000081b7b105e8a60690 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> We've previously discussed making a certain key s= equence disable font
> locking in a buffer -- or blacklist the partic= ular functions that's
> inflooping somehow.

I think from a= user point of view a _special_ sequence is a bad idea,
as most users wo= n't know about it.

Blacklisting I'd say is even worse, becau= se that would mean a user
first have to expirience a hang of Emacs, find= out _which_ function
caused it (remember, that Emacs is either unrespon= sive or is killed by
now), find out that it is possible to blacklist it = and do it. Way too
much to expect from a user.

Besides, a functio= n may not be outright malicious, only buggy in
certain corner-cases, so = it would be much nicer to be able to
force-abort it when that happens. E= .g. in my case this happened in
Logview mode, because it expected `widen= ' to, well, widen, but Emacs
`master' introduced half-cooked nar= rowed locking that broke that
expectation and then Logview fell into an = infinite loop, because the
buffer was not in the state the mode expected= it to be.

> For instance, if the user hits `C-g' three times= (and Emacs doesn't idle
> in between), then we disable font-lock= in that buffer.

That sounds much better. I know that `C-g' is w= hat to press when Emacs
is stuck.

> There's also `max-redi= splay-ticks' -- but I'm not sure that would have
> helped her= e?

If I add `(setf max-redisplay-ticks 100)' right after enterin= g
`buggy-mode', it seems to have some effect, but not exactly what I= 'd
hope on. I suggest you try and see for yourself, hard to describe=
them.

Paul
--00000000000081b7b105e8a60690--