From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#61436: Emacs Freezing With Java Files Date: Thu, 12 Oct 2023 21:58:06 +0200 Message-ID: <875y3bbokx.fsf@sappc2.fritz.box> References: <83cz6fiefb.fsf@gnu.org> <835yc6hl0c.fsf@gnu.org> <87bkd7fsp4.fsf@sappc2.fritz.box> <87il7ew5wx.fsf@sappc2.fritz.box> <87il7dbosk.fsf@lidells.se> <87r0m1t0el.fsf@sappc2.fritz.box> Reply-To: Jens Schmidt Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8270"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: Robert Weiner , Hank Greenburg , Mats Lidell , Eli Zaretskii , rswgnu@gmail.com, 61436@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 12 22:00:05 2023 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 1qr1qm-0001tp-NM for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 12 Oct 2023 22:00:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qr1qP-0005Uq-Dx; Thu, 12 Oct 2023 15:59:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qr1qO-0005Uh-AG for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2023 15:59:40 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qr1qO-0005RP-2S for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2023 15:59:40 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qr1qk-0002CN-IC for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2023 16:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jens Schmidt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2023 20:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61436 X-GNU-PR-Package: emacs Original-Received: via spool by 61436-submit@debbugs.gnu.org id=B61436.16971407488338 (code B ref 61436); Thu, 12 Oct 2023 20:00:02 +0000 Original-Received: (at 61436) by debbugs.gnu.org; 12 Oct 2023 19:59:08 +0000 Original-Received: from localhost ([127.0.0.1]:44328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qr1pr-0002AQ-Dt for submit@debbugs.gnu.org; Thu, 12 Oct 2023 15:59:07 -0400 Original-Received: from mr5.vodafonemail.de ([145.253.228.165]:34608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qr1pm-00029a-33 for 61436@debbugs.gnu.org; Thu, 12 Oct 2023 15:59:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafonemail.de; s=vfde-mb-mr2-21dec; t=1697140714; bh=AMps77Trf0zmFk5p7XIee+hJtP7QyIVCAnYFTD0Dlf8=; h=From:To:Subject:References:Date:In-Reply-To:Message-ID:User-Agent: Content-Type:From; b=TdQ5zvmJpsGdZwmH56VYybPyZj3nDuPi9iKbPWO/NIvpluXMboBAwD8iYyGTONvsf zBudEF6dPRgZyBxkSYmj/pOW3BRsZyq94v2KiBeXQHOTokc/ib9GdM1/TmwQvQHRld e/0Bgn5WvX494uPn/UYvH5RKwcMPNy9D+GRuepAs= Original-Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr5.vodafonemail.de (Postfix) with ESMTPS id 4S60nP62Lxz1y9J; Thu, 12 Oct 2023 19:58:33 +0000 (UTC) Original-Received: from sappc2 (port-92-194-185-170.dynamic.as20676.net [92.194.185.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4S60my5jK2z9s6R; Thu, 12 Oct 2023 19:58:07 +0000 (UTC) In-Reply-To: (Alan Mackenzie's message of "Wed, 11 Oct 2023 22:03:05 +0000") X-purgate-type: clean X-purgate: clean X-purgate-size: 4583 X-purgate-ID: 155817::1697140709-F97F97FF-1EB2DCC7/0/0 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272318 Archived-At: Hi Alan, Alan Mackenzie writes: > It may well be that persevering with this regexp is a lost cause, and > you'd do better to construct a new regexp from scratch using more > structured methods (perhaps something similar to what's in cc-awk.el). > In fact the regexp looks horribly like one in the CC Mode manual which > was explicitly designated unsupported. ;-( and thanks for your analysis. I felt as well that this regexp looks, well, funny, but what intrigues me is that it cannot (only) be the complexity and ill-conditioned-ness of that regexp that lets Emacs freeze. >> That always freezes Emacs (29 and master) even before it has a chance to >> display P1.java. The freeze happens in function >> `c-get-fallback-scan-pos', where the while loop inf-loops. > > c-get-fallback-scan-pos tries to move to the beginning of a function. > This probably involves defun-prompt-regexp when it is non-nil. :-( Otherwise we would see hangs or exponential behavior (?) somewhere in the Emacs regexp machinerie, but they take place in that while loop. So I guess that there must be some other, additional quality that this regexp fulfills. Like: "matches the empty string" (which it does not, as far as I can tell) or: "must only match before curlies" or whatnot. Unfortunately, the doc string/info doc of `defun-prompt-regexp=C2=B4 provid= es only exactly that latter criterion: That is to say, a defun begins on a line that starts with a match for this regular expression, followed by a character with open-parenthesis syntax. I guess that only pruning that regexp until things start unfreezing could give an answer here. Or more tracing to see how point moves in `c-get-fallback-scan-pos'. But I need some tracing break here ... ... or so I thought, I just couldn't resist: I expanded and instrumented that function from emacs-29 as follows, (hopefully) not changing any of its logic: ------------------------- snip ------------------------- (defun c-get-fallback-scan-pos (here) ;; Return a start position for building `c-state-cache' from scratch. Th= is ;; will be at the top level, 2 defuns back. Return nil if we don't find ;; these defun starts a reasonable way back. (message "c-get-fallback-scan-pos") (save-excursion (save-restriction (when (> here (* 10 c-state-cache-too-far)) (narrow-to-region (- here (* 10 c-state-cache-too-far)) here)) ;; Go back 2 bods, but ignore any bogus positions returned by ;; beginning-of-defun (i.e. open paren in column zero). (goto-char here) (let ((cnt 2)) (message "beginning-of-defun-loop-00: %d %d" cnt (point)) (while (not (or (bobp) (zerop cnt))) (message "beginning-of-defun-loop-01: %d" (point)) (let (beginning-of-defun-function end-of-defun-function) (beginning-of-defun)) (and defun-prompt-regexp (looking-at defun-prompt-regexp) (message "beginning-of-defun-loop-02: %d" (point)) (goto-char (match-end 0))) (message "beginning-of-defun-loop-03: %d" (point)) (if (eq (char-after) ?\{) (setq cnt (1- cnt))))) (and (not (bobp)) (point))))) ------------------------- snip ------------------------- That results in the message triple ------------------------- snip ------------------------- beginning-of-defun-loop-01: 5879 beginning-of-defun-loop-02: 5801 beginning-of-defun-loop-03: 5879 beginning-of-defun-loop-01: 5879 beginning-of-defun-loop-02: 5801 beginning-of-defun-loop-03: 5879 ... ------------------------- snip ------------------------- inf-looping. These points are (|: 5801, ^: 5879) here in P1.java: ------------------------- snip ------------------------- 178 } catch (Exception e) { 179| error("symTable.addDecl", "unexpected error with a single HashMap= " + e)^; 180 } 181 ------------------------- snip ------------------------- So the catch-block just before line 181 is recognized as a potential BOD (previous trailing open curly?). But then `defun-prompt-regexp' matches the function call in the catch-block as defun prompt regexp (which it better should not?), taking point back to where, on next BOD search, the exact previous BOD is found again. So probably there are really two issues here: 1. The `defun-prompt-regexp' used by Hyperbole, which matches too broadly, and 2. function `c-get-fallback-scan-pos', which could try harder to avoid inf-loops when such things happen. But that's where I *really* stop here :-)