From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 14 16:04:43 2023 Received: (at submit) by debbugs.gnu.org; 14 Feb 2023 21:04:43 +0000 Received: from localhost ([127.0.0.1]:57156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS2Th-0003qi-Uf for submit@debbugs.gnu.org; Tue, 14 Feb 2023 16:04:43 -0500 Received: from lists.gnu.org ([209.51.188.17]:44802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS2Tf-0003qY-0X for submit@debbugs.gnu.org; Tue, 14 Feb 2023 16:04:40 -0500 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 1pS2TZ-0001tw-Sl for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 16:04:33 -0500 Received: from spam1.m5hosting.com ([206.71.179.219]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pS2TV-0005uE-Sc for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 16:04:33 -0500 Received: from mail.nichework.com ([108.161.151.158]) by spam1.m5hosting.com with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pS2TC-0001Fw-Sl for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 13:04:20 -0800 Received: from mail.nichework.com (localhost [127.0.0.1]) by mail.nichework.com (Postfix) with ESMTPS id 2F0344E0452 for ; Tue, 14 Feb 2023 13:04:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nichework.com (Postfix) with ESMTP id 064AC4E05B2 for ; Tue, 14 Feb 2023 13:04:10 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.nichework.com 064AC4E05B2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=everybody.org; s=C75414D8-59CA-11EA-A864-6C07A2A44C35; t=1676408650; bh=vXLP12AfiSIp63Fu4xGM3AkeX1Cpa3W94FhZCOsCqxI=; h=From:To:Date:Message-ID:MIME-Version; b=ppT5IUgNRAEfD3gnjNpUIWLAdQKW2TC0vhuCKh8k63Hpn5cNIqtiyWYIvR2b3W9h1 0fv2lsJpEKc8LMMpYYweAIkMCrEplIHnof8q3Fy8jrrH/wNPtaLTFgeVH76+KGneDp SDb84wBVNuY6rAh/dJkiL2Fv0xts/frKPq2dg201zH6xQd3gIkB85bEpXlZCjLclnR NZdgR8/ijjCquyHNLNi1cI6EPnWCYqGh0qUxTvVCzMjNRmetD1R8T9ifnY3+tH0Ozb EYT1/boUVOE+ss9xWkQmMDmyefcNYadZbw2Z+qwDXEZPaMowrvq2/qYn+lbWh5fC5/ To98y7GcEJWYQ== Received: from mail.nichework.com ([127.0.0.1]) by localhost (mail.nichework.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n-1qVUmuo5T3 for ; Tue, 14 Feb 2023 13:04:09 -0800 (PST) Received: from gabriel.everybody.org (209-253-11-93.ip.mcleodusa.net [209.253.11.93]) by mail.nichework.com (Postfix) with ESMTPSA id 965744E0452 for ; Tue, 14 Feb 2023 13:04:09 -0800 (PST) From: "Mark A. Hershberger" To: bug-gnu-emacs@gnu.org Subject: 30.0.50; sadistically long xml line hangs emacs Date: Tue, 14 Feb 2023 16:02:04 -0500 Message-ID: <87lel0c65v.fsf@everybody.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 108.161.151.158 X-SpamExperts-Domain: out.m5hosting.com X-SpamExperts-Username: 108.161.151.158 Authentication-Results: m5hosting.com; auth=pass smtp.auth=108.161.151.158@out.m5hosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: SB/global_tokens (0.00177587214929) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/bkvvQX+R8elVqjbLHBrXJPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wlAxozo778b01LESzM9ruWD181ZRkJ75zosNBWoY/fPNcV PSoHm0W/3adFfiYl2nsDAgd8EhjXhNxK2iaC5ZBC/T4GcPvCLvSpAEEGy7kYxtLSm6ZPIIlKlwTC gIG9JyxEDs7WWa47hTVCppybiVa5BGjzuh4BML6Ea1s3IuoPv4YaJE+7Na2E3Oj46THdq0PQpijq RT1J+q3zA0F+F5/8TcWsqU26dvDcYIYzaKVPzmqo+CiEiEUieTH4xPDmrp2RMmGH+05pSN4hHKly uAOt4xNuSfrPV+ybw2gxV1Svw0QMF99VlWOZVo1sbhkkbsWwPVI/rahiZln9WaSEpal3cgXNOE5B iBPvUc+zssFNXm1kHkAJl9I0+cmjX7E2n2Y6rDn0tTOVcmJwqI8Ju2neCJuKmef1JCbmfgcv6zoJ wCAFxzML6QwN9QbWIKr2lWnaleDArnyiHVL+9m1Yi9b42+mjZSBX08/Qa05JAIPdanoSKlHMxVnk urBPHtW+f1JZBGKGpZFwJprvIwY1weIqboZ9k8ttCKjZelN1W89BkXn+HbCzapSJWJ1lLYwGze8i c5cOiPJd4s2U3aQ6oVZrauB9ERPk6JDy91qzxpJfKD+cDAWn/LMqWnQoM5MEPwtEz5VneUBrVnXk 5sly1vIf1P3k2kPy9wmDetZJiaD6+R+DVhN7hxa0Zvgvtl7SOShNSM4gYl1pOOZWclDXAOPdoPmE TXCqaiBIEGOPkonGHuW323yvE8gx3tyRbkQY0g5c9aUV1oY4fX3W5eOCNA39llhhiyU/u3DNrpT6 tnfpbM+mHwng77VK4UgpvEvKb9u7PgcbCQQ3YUwyJajT85+s14T/CLazzQhWdmB8bxplErYUTYLO yIOJf1xK6WJ94JX8bXqCTAJqOjMpfgWS/maoStpSjEcfuNRofyRSNl4Pfg5K/mljQzDNGRc7+LVI He83nhE7MuYv2Yds0bd8TZ75MS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@spam1.m5hosting.com Received-SPF: pass client-ip=206.71.179.219; envelope-from=mah@everybody.org; helo=spam1.m5hosting.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) There seems to be a regression between 28 and 30 with how emacs handles long lines. Reading a comparision of editors, I came across this test case: It's interesting how some Linux editors handle huge lines. Tested several editors on Ubuntu 19.10 on Intel i3 CPU. With XML file with a single line of length 4M. XML file contains line like with the huge "name" value of 4M. Python script to generate test file: #!/usr/bin/python3 f =3D open("a.xml", "w") f.write('\n') From https://wiki.lazarus.freepascal.org/CudaText_VS_other_editors#Performance_o= n_huge_lines I know Emacs has problems with long lines, but the examples on this page referred to Emacs 26, so I thought I would see how things have changed. Opening the file (a.xml) produced by the script above from a dired buffer in Emacs 30.0.50 shows the following in the message window: RNG NXML error: (error "Stack overflow in regexp matcher") After this, Emacs appears to hang and nothing else is displayed. The mouse cursor does not change to indicate that any processing is happening. It changes to an arrow over clickable areas (e.g. the menu bar) and a vertical bar over the dired buffer. Hitting C-g does nothing. Resizing the window does not properly redraw it. Attempting to close the window does nothing. Build config for Emacs 30.0.50 below. For comparison, Emacs 28.2 (from Debian repo) opens the file but displays opens the file but the *Messages* buffer contains: Error: (error "Stack overflow in regexp matcher") Error during redisplay: (jit-lock-function 1) signaled (error "Stack ov= erflow in regexp matcher") Error during redisplay: (jit-lock-function 1501) signaled (error "Stack= overflow in regexp matcher") Internal error in rng-validate-mode triggered at buffer position 5. Sta= ck overflow in regexp matcher Moving point in the buffer displayed seems to work somewhat normally, but hitting C-e to go to the end of the line takes a bit and then keyboard navigation seems problematic while the *Messages* buffer fills with =E2=80=9CError during redisplay=E2=80=9D messages. Bottom line: Emacs 30 is handling files with long lines worse than Emacs 28. Output from report-emacs-bug continues: In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo version 1.16.0) of 2023-02-10 built on gabriel Repository revision: ea29622e928f50522e424ee59b0f24bbb5a42eca Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12201007 System Description: Debian GNU/Linux bookworm/sid Configured using: 'configure --with-gif=3Difavailable --with-tree-sitter=3Difavailable --with-cairo --with-imagemagick --with-json --with-native-compilation --with-xinput2 --with-xwidgets --with-x-toolkit=3Dgtk3 --with-gconf --with-xwidgets --with-imagemagick --with-modules' Configured features: ACL CAIRO DBUS FREETYPE GCONF GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB Important settings: value of $LC_MONETARY: en_US.UTF-8 value of $LC_NUMERIC: en_US.UTF-8 value of $LC_TIME: en_US.UTF-8 value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=3Dibus locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: helm--remap-mouse-mode: t async-bytecomp-package-mode: t global-emojify-mode: t emojify-mode: t which-key-mode: t global-page-break-lines-mode: t page-break-lines-mode: t buffer-face-mode: t direnv-mode: t flx-ido-mode: t auto-compile-on-load-mode: t auto-compile-on-save-mode: t yas-global-mode: t yas-minor-mode: t gcmh-mode: t global-flycheck-mode: t flycheck-mode: t override-global-mode: t shell-dirtrack-mode: t server-mode: t ido-everywhere: t windmove-mode: t display-time-mode: t straight-use-package-mode: t straight-package-neutering-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t prettify-symbols-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t abbrev-mode: t hs-minor-mode: t Load-path shadows: /home/mah/.emacs.d/straight/build/dpkg-dev-el/debian-autoloads hides /home/= mah/.emacs.d/straight/build/debian-el/debian-autoloads /home/mah/.emacs.d/straight/build/transient/transient hides /home/mah/work/= code/emacs-master/lisp/transient /home/mah/.emacs.d/straight/build/use-package/use-package hides /home/mah/w= ork/code/emacs-master/lisp/use-package/use-package /home/mah/.emacs.d/straight/build/use-package/use-package-bind-key hides /h= ome/mah/work/code/emacs-master/lisp/use-package/use-package-bind-key /home/mah/.emacs.d/straight/build/use-package/use-package-core hides /home/= mah/work/code/emacs-master/lisp/use-package/use-package-core /home/mah/.emacs.d/straight/build/use-package/use-package-delight hides /ho= me/mah/work/code/emacs-master/lisp/use-package/use-package-delight /home/mah/.emacs.d/straight/build/use-package/use-package-jump hides /home/= mah/work/code/emacs-master/lisp/use-package/use-package-jump /home/mah/.emacs.d/straight/build/use-package/use-package-ensure hides /hom= e/mah/work/code/emacs-master/lisp/use-package/use-package-ensure /home/mah/.emacs.d/straight/build/use-package/use-package-diminish hides /h= ome/mah/work/code/emacs-master/lisp/use-package/use-package-diminish /home/mah/.emacs.d/straight/build/use-package/use-package-lint hides /home/= mah/work/code/emacs-master/lisp/use-package/use-package-lint /home/mah/.emacs.d/straight/build/bind-key/bind-key hides /home/mah/work/co= de/emacs-master/lisp/use-package/bind-key /home/mah/.emacs.d/straight/build/xref/xref hides /home/mah/work/code/emacs= -master/lisp/progmodes/xref /home/mah/.emacs.d/straight/build/project/project hides /home/mah/work/code= /emacs-master/lisp/progmodes/project /home/mah/.emacs.d/straight/build/org/org-fold hides /home/mah/work/code/em= acs-master/lisp/org/org-fold /home/mah/.emacs.d/straight/build/org/ob-tangle hides /home/mah/work/code/e= macs-master/lisp/org/ob-tangle /home/mah/.emacs.d/straight/build/org/org-datetree hides /home/mah/work/cod= e/emacs-master/lisp/org/org-datetree /home/mah/.emacs.d/straight/build/org/ob-makefile hides /home/mah/work/code= /emacs-master/lisp/org/ob-makefile /home/mah/.emacs.d/straight/build/org/org-goto hides /home/mah/work/code/em= acs-master/lisp/org/org-goto /home/mah/.emacs.d/straight/build/org/org-timer hides /home/mah/work/code/e= macs-master/lisp/org/org-timer /home/mah/.emacs.d/straight/build/org/ob-julia hides /home/mah/work/code/em= acs-master/lisp/org/ob-julia /home/mah/.emacs.d/straight/build/org/ob-eshell hides /home/mah/work/code/e= macs-master/lisp/org/ob-eshell /home/mah/.emacs.d/straight/build/org/org-macro hides /home/mah/work/code/e= macs-master/lisp/org/org-macro /home/mah/.emacs.d/straight/build/org/ol-eshell hides /home/mah/work/code/e= macs-master/lisp/org/ol-eshell /home/mah/.emacs.d/straight/build/org/ob-emacs-lisp hides /home/mah/work/co= de/emacs-master/lisp/org/ob-emacs-lisp /home/mah/.emacs.d/straight/build/org/ob-fortran hides /home/mah/work/code/= emacs-master/lisp/org/ob-fortran /home/mah/.emacs.d/straight/build/org/ol-eww hides /home/mah/work/code/emac= s-master/lisp/org/ol-eww /home/mah/.emacs.d/straight/build/org/ol-mhe hides /home/mah/work/code/emac= s-master/lisp/org/ol-mhe /home/mah/.emacs.d/straight/build/org/ol-irc hides /home/mah/work/code/emac= s-master/lisp/org/ol-irc /home/mah/.emacs.d/straight/build/org/ox-org hides /home/mah/work/code/emac= s-master/lisp/org/ox-org /home/mah/.emacs.d/straight/build/org/org-lint hides /home/mah/work/code/em= acs-master/lisp/org/org-lint /home/mah/.emacs.d/straight/build/org/ob-core hides /home/mah/work/code/ema= cs-master/lisp/org/ob-core /home/mah/.emacs.d/straight/build/org/org-list hides /home/mah/work/code/em= acs-master/lisp/org/org-list /home/mah/.emacs.d/straight/build/org/org-compat hides /home/mah/work/code/= emacs-master/lisp/org/org-compat /home/mah/.emacs.d/straight/build/org/ox-man hides /home/mah/work/code/emac= s-master/lisp/org/ox-man /home/mah/.emacs.d/straight/build/org/org-persist hides /home/mah/work/code= /emacs-master/lisp/org/org-persist /home/mah/.emacs.d/straight/build/org/ob-org hides /home/mah/work/code/emac= s-master/lisp/org/ob-org /home/mah/.emacs.d/straight/build/org/ob-table hides /home/mah/work/code/em= acs-master/lisp/org/ob-table /home/mah/.emacs.d/straight/build/org/ol-bibtex hides /home/mah/work/code/e= macs-master/lisp/org/ol-bibtex /home/mah/.emacs.d/straight/build/org/org-element hides /home/mah/work/code= /emacs-master/lisp/org/org-element /home/mah/.emacs.d/straight/build/org/oc-natbib hides /home/mah/work/code/e= macs-master/lisp/org/oc-natbib /home/mah/.emacs.d/straight/build/org/ob-ocaml hides /home/mah/work/code/em= acs-master/lisp/org/ob-ocaml /home/mah/.emacs.d/straight/build/org/org-agenda hides /home/mah/work/code/= emacs-master/lisp/org/org-agenda /home/mah/.emacs.d/straight/build/org/ob-sqlite hides /home/mah/work/code/e= macs-master/lisp/org/ob-sqlite /home/mah/.emacs.d/straight/build/org/ol-bbdb hides /home/mah/work/code/ema= cs-master/lisp/org/ol-bbdb /home/mah/.emacs.d/straight/build/org/ob-ref hides /home/mah/work/code/emac= s-master/lisp/org/ob-ref /home/mah/.emacs.d/straight/build/org/ox-latex hides /home/mah/work/code/em= acs-master/lisp/org/ox-latex /home/mah/.emacs.d/straight/build/org/org-loaddefs hides /home/mah/work/cod= e/emacs-master/lisp/org/org-loaddefs /home/mah/.emacs.d/straight/build/org/org-fold-core hides /home/mah/work/co= de/emacs-master/lisp/org/org-fold-core /home/mah/.emacs.d/straight/build/org/ob-ditaa hides /home/mah/work/code/em= acs-master/lisp/org/ob-ditaa /home/mah/.emacs.d/straight/build/org/ox-beamer hides /home/mah/work/code/e= macs-master/lisp/org/ox-beamer /home/mah/.emacs.d/straight/build/org/ob-clojure hides /home/mah/work/code/= emacs-master/lisp/org/ob-clojure /home/mah/.emacs.d/straight/build/org/ob-haskell hides /home/mah/work/code/= emacs-master/lisp/org/ob-haskell /home/mah/.emacs.d/straight/build/org/ob-sql hides /home/mah/work/code/emac= s-master/lisp/org/ob-sql /home/mah/.emacs.d/straight/build/org/ob-matlab hides /home/mah/work/code/e= macs-master/lisp/org/ob-matlab /home/mah/.emacs.d/straight/build/org/org-num hides /home/mah/work/code/ema= cs-master/lisp/org/org-num /home/mah/.emacs.d/straight/build/org/ob-R hides /home/mah/work/code/emacs-= master/lisp/org/ob-R /home/mah/.emacs.d/straight/build/org/ob-js hides /home/mah/work/code/emacs= -master/lisp/org/ob-js /home/mah/.emacs.d/straight/build/org/ox-ascii hides /home/mah/work/code/em= acs-master/lisp/org/ox-ascii /home/mah/.emacs.d/straight/build/org/org-entities hides /home/mah/work/cod= e/emacs-master/lisp/org/org-entities /home/mah/.emacs.d/straight/build/org/org-plot hides /home/mah/work/code/em= acs-master/lisp/org/org-plot /home/mah/.emacs.d/straight/build/org/ob-shell hides /home/mah/work/code/em= acs-master/lisp/org/ob-shell /home/mah/.emacs.d/straight/build/org/oc hides /home/mah/work/code/emacs-ma= ster/lisp/org/oc /home/mah/.emacs.d/straight/build/org/oc-biblatex hides /home/mah/work/code= /emacs-master/lisp/org/oc-biblatex /home/mah/.emacs.d/straight/build/org/org-ctags hides /home/mah/work/code/e= macs-master/lisp/org/org-ctags /home/mah/.emacs.d/straight/build/org/org-habit hides /home/mah/work/code/e= macs-master/lisp/org/org-habit /home/mah/.emacs.d/straight/build/org/ob-perl hides /home/mah/work/code/ema= cs-master/lisp/org/ob-perl /home/mah/.emacs.d/straight/build/org/org-table hides /home/mah/work/code/e= macs-master/lisp/org/org-table /home/mah/.emacs.d/straight/build/org/ob-calc hides /home/mah/work/code/ema= cs-master/lisp/org/ob-calc /home/mah/.emacs.d/straight/build/org/oc-bibtex hides /home/mah/work/code/e= macs-master/lisp/org/oc-bibtex /home/mah/.emacs.d/straight/build/org/ob-octave hides /home/mah/work/code/e= macs-master/lisp/org/ob-octave /home/mah/.emacs.d/straight/build/org/ob-maxima hides /home/mah/work/code/e= macs-master/lisp/org/ob-maxima /home/mah/.emacs.d/straight/build/org/ol hides /home/mah/work/code/emacs-ma= ster/lisp/org/ol /home/mah/.emacs.d/straight/build/org/org-inlinetask hides /home/mah/work/c= ode/emacs-master/lisp/org/org-inlinetask /home/mah/.emacs.d/straight/build/org/ox-koma-letter hides /home/mah/work/c= ode/emacs-master/lisp/org/ox-koma-letter /home/mah/.emacs.d/straight/build/org/org-cycle hides /home/mah/work/code/e= macs-master/lisp/org/org-cycle /home/mah/.emacs.d/straight/build/org/ob-latex hides /home/mah/work/code/em= acs-master/lisp/org/ob-latex /home/mah/.emacs.d/straight/build/org/org-indent hides /home/mah/work/code/= emacs-master/lisp/org/org-indent /home/mah/.emacs.d/straight/build/org/ol-gnus hides /home/mah/work/code/ema= cs-master/lisp/org/ol-gnus /home/mah/.emacs.d/straight/build/org/org-refile hides /home/mah/work/code/= emacs-master/lisp/org/org-refile /home/mah/.emacs.d/straight/build/org/ob-sed hides /home/mah/work/code/emac= s-master/lisp/org/ob-sed /home/mah/.emacs.d/straight/build/org/org-attach-git hides /home/mah/work/c= ode/emacs-master/lisp/org/org-attach-git /home/mah/.emacs.d/straight/build/org/org-colview hides /home/mah/work/code= /emacs-master/lisp/org/org-colview /home/mah/.emacs.d/straight/build/org/ob-groovy hides /home/mah/work/code/e= macs-master/lisp/org/ob-groovy /home/mah/.emacs.d/straight/build/org/ob-lisp hides /home/mah/work/code/ema= cs-master/lisp/org/ob-lisp /home/mah/.emacs.d/straight/build/org/org-protocol hides /home/mah/work/cod= e/emacs-master/lisp/org/org-protocol /home/mah/.emacs.d/straight/build/org/ol-doi hides /home/mah/work/code/emac= s-master/lisp/org/ol-doi /home/mah/.emacs.d/straight/build/org/ob-ruby hides /home/mah/work/code/ema= cs-master/lisp/org/ob-ruby /home/mah/.emacs.d/straight/build/org/ox-texinfo hides /home/mah/work/code/= emacs-master/lisp/org/ox-texinfo /home/mah/.emacs.d/straight/build/org/ob-eval hides /home/mah/work/code/ema= cs-master/lisp/org/ob-eval /home/mah/.emacs.d/straight/build/org/ob-dot hides /home/mah/work/code/emac= s-master/lisp/org/ob-dot /home/mah/.emacs.d/straight/build/org/org-feed hides /home/mah/work/code/em= acs-master/lisp/org/org-feed /home/mah/.emacs.d/straight/build/org/ox-odt hides /home/mah/work/code/emac= s-master/lisp/org/ox-odt /home/mah/.emacs.d/straight/build/org/ob-plantuml hides /home/mah/work/code= /emacs-master/lisp/org/ob-plantuml /home/mah/.emacs.d/straight/build/org/ol-docview hides /home/mah/work/code/= emacs-master/lisp/org/ol-docview /home/mah/.emacs.d/straight/build/org/ob-lob hides /home/mah/work/code/emac= s-master/lisp/org/ob-lob /home/mah/.emacs.d/straight/build/org/ob-awk hides /home/mah/work/code/emac= s-master/lisp/org/ob-awk /home/mah/.emacs.d/straight/build/org/ox-publish hides /home/mah/work/code/= emacs-master/lisp/org/ox-publish /home/mah/.emacs.d/straight/build/org/ox-html hides /home/mah/work/code/ema= cs-master/lisp/org/ox-html /home/mah/.emacs.d/straight/build/org/org hides /home/mah/work/code/emacs-m= aster/lisp/org/org /home/mah/.emacs.d/straight/build/org/org-src hides /home/mah/work/code/ema= cs-master/lisp/org/org-src /home/mah/.emacs.d/straight/build/org/ol-w3m hides /home/mah/work/code/emac= s-master/lisp/org/ol-w3m /home/mah/.emacs.d/straight/build/org/ox hides /home/mah/work/code/emacs-ma= ster/lisp/org/ox /home/mah/.emacs.d/straight/build/org/ob-C hides /home/mah/work/code/emacs-= master/lisp/org/ob-C /home/mah/.emacs.d/straight/build/org/oc-basic hides /home/mah/work/code/em= acs-master/lisp/org/oc-basic /home/mah/.emacs.d/straight/build/org/ob-screen hides /home/mah/work/code/e= macs-master/lisp/org/ob-screen /home/mah/.emacs.d/straight/build/org/ob-processing hides /home/mah/work/co= de/emacs-master/lisp/org/ob-processing /home/mah/.emacs.d/straight/build/org/ob-sass hides /home/mah/work/code/ema= cs-master/lisp/org/ob-sass /home/mah/.emacs.d/straight/build/org/ol-man hides /home/mah/work/code/emac= s-master/lisp/org/ol-man /home/mah/.emacs.d/straight/build/org/org-version hides /home/mah/work/code= /emacs-master/lisp/org/org-version /home/mah/.emacs.d/straight/build/org/org-keys hides /home/mah/work/code/em= acs-master/lisp/org/org-keys /home/mah/.emacs.d/straight/build/org/ox-md hides /home/mah/work/code/emacs= -master/lisp/org/ox-md /home/mah/.emacs.d/straight/build/org/org-capture hides /home/mah/work/code= /emacs-master/lisp/org/org-capture /home/mah/.emacs.d/straight/build/org/ob-lua hides /home/mah/work/code/emac= s-master/lisp/org/ob-lua /home/mah/.emacs.d/straight/build/org/org-duration hides /home/mah/work/cod= e/emacs-master/lisp/org/org-duration /home/mah/.emacs.d/straight/build/org/org-footnote hides /home/mah/work/cod= e/emacs-master/lisp/org/org-footnote /home/mah/.emacs.d/straight/build/org/org-macs hides /home/mah/work/code/em= acs-master/lisp/org/org-macs /home/mah/.emacs.d/straight/build/org/org-tempo hides /home/mah/work/code/e= macs-master/lisp/org/org-tempo /home/mah/.emacs.d/straight/build/org/ob-lilypond hides /home/mah/work/code= /emacs-master/lisp/org/ob-lilypond /home/mah/.emacs.d/straight/build/org/ob-exp hides /home/mah/work/code/emac= s-master/lisp/org/ob-exp /home/mah/.emacs.d/straight/build/org/ob-python hides /home/mah/work/code/e= macs-master/lisp/org/ob-python /home/mah/.emacs.d/straight/build/org/ol-info hides /home/mah/work/code/ema= cs-master/lisp/org/ol-info /home/mah/.emacs.d/straight/build/org/org-pcomplete hides /home/mah/work/co= de/emacs-master/lisp/org/org-pcomplete /home/mah/.emacs.d/straight/build/org/org-attach hides /home/mah/work/code/= emacs-master/lisp/org/org-attach /home/mah/.emacs.d/straight/build/org/org-archive hides /home/mah/work/code= /emacs-master/lisp/org/org-archive /home/mah/.emacs.d/straight/build/org/ol-rmail hides /home/mah/work/code/em= acs-master/lisp/org/ol-rmail /home/mah/.emacs.d/straight/build/org/org-id hides /home/mah/work/code/emac= s-master/lisp/org/org-id /home/mah/.emacs.d/straight/build/org/org-crypt hides /home/mah/work/code/e= macs-master/lisp/org/org-crypt /home/mah/.emacs.d/straight/build/org/ob-java hides /home/mah/work/code/ema= cs-master/lisp/org/ob-java /home/mah/.emacs.d/straight/build/org/ob-css hides /home/mah/work/code/emac= s-master/lisp/org/ob-css /home/mah/.emacs.d/straight/build/org/ob-scheme hides /home/mah/work/code/e= macs-master/lisp/org/ob-scheme /home/mah/.emacs.d/straight/build/org/org-faces hides /home/mah/work/code/e= macs-master/lisp/org/org-faces /home/mah/.emacs.d/straight/build/org/ob hides /home/mah/work/code/emacs-ma= ster/lisp/org/ob /home/mah/.emacs.d/straight/build/org/ob-comint hides /home/mah/work/code/e= macs-master/lisp/org/ob-comint /home/mah/.emacs.d/straight/build/org/org-mobile hides /home/mah/work/code/= emacs-master/lisp/org/org-mobile /home/mah/.emacs.d/straight/build/org/ob-forth hides /home/mah/work/code/em= acs-master/lisp/org/ob-forth /home/mah/.emacs.d/straight/build/org/org-clock hides /home/mah/work/code/e= macs-master/lisp/org/org-clock /home/mah/.emacs.d/straight/build/org/ox-icalendar hides /home/mah/work/cod= e/emacs-master/lisp/org/ox-icalendar /home/mah/.emacs.d/straight/build/org/oc-csl hides /home/mah/work/code/emac= s-master/lisp/org/oc-csl /home/mah/.emacs.d/straight/build/org/org-mouse hides /home/mah/work/code/e= macs-master/lisp/org/org-mouse /home/mah/.emacs.d/straight/build/org/ob-gnuplot hides /home/mah/work/code/= emacs-master/lisp/org/ob-gnuplot /home/mah/.emacs.d/straight/build/let-alist/let-alist hides /home/mah/work/= code/emacs-master/lisp/emacs-lisp/let-alist Features: (shadow sort mail-extr emacsbug winner ffap tramp-archive tramp-gvfs tramp-cache zeroconf helm-command helm-elisp helm-eval edebug debug backtrace helm-info helm-mode helm-misc helm-git-grep helm-files image-dired image-dired-tags image-dired-external image-dired-util image-mode exif helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp helm-utils helm-help helm-types cl helm helm-global-bindings helm-easymenu helm-core async-bytecomp helm-source helm-multi-match helm-lib async hideshow emojify tar-mode arc-mode archive-mode init cal-china lunar solar cal-dst cal-hebrew cal-julian holidays holiday-loaddefs terraform-mode hcl-mode terraform-mode-autoloads hcl-mode-autoloads terraform-doc terraform-doc-autoloads html-fold html-fold-autoloads danneskjold-theme danneskjold-theme-autoloads dpkg-dev-el-autoloads dpkg-dev-el debian-el-autoloads debian-el which-key which-key-autoloads prettier-js-autoloads impatient-mode htmlize simple-httpd impatient-mode-autoloads simple-httpd-autoloads web-mode-autoloads whattf-dt html5-langs whattf-dt-autoloads rustic-autoloads xterm-color-autoloads spinner-autoloads project-autoloads xref-autoloads rust-mode-autoloads flycheck-rust flycheck-rust-autoloads feature-mode cucumber-mode etags fileloop feature-mode-autoloads markdown-xwidget-autoloads mustache-autoloads phpcbf phpcbf-autoloads dockerfile-mode-autoloads nov-autoloads esxml-autoloads kv-autoloads go-errcheck-autoloads go-mode-autoloads blamer-autoloads git-timemachine vc-git vc-dispatcher git-timemachine-autoloads treemacs-autoloads cfrs-autoloads posframe-autoloads pfuture-autoloads ace-window-autoloads lice lice-autoloads gnus-alias gnus-alias-autoloads lorem-ipsum-autoloads ox-moderncv org-cv-utils ox-moderncv-autoloads magit-tramp-autoloads magit-gitflow-autoloads magit-popup-autoloads orgit-forge-autoloads orgit-autoloads web time-stamp web-autoloads ghub+ apiwrap apropos ghub+-autoloads apiwrap-autoloads ox-mediawiki-autoloads org-download-autoloads org-ref org-ref-core org-ref-glossary org-ref-bibtex avy doi-utils org-ref-utils org-ref-export citeproc citeproc-itemgetters citeproc-biblatex citeproc-bibtex ol-bibtex citeproc-cite citeproc-subbibs citeproc-sort citeproc-name citeproc-formatters citeproc-number rst citeproc-proc citeproc-disamb citeproc-itemdata citeproc-generic-elements citeproc-macro citeproc-choose citeproc-date citeproc-context citeproc-prange citeproc-style citeproc-locale citeproc-term citeproc-rt citeproc-lib citeproc-s thingatpt queue org-ref-misc-links org-ref-label-link org-ref-ref-links org-ref-citation-links xref project org-ref-bibliography-links hydra lv bibtex-completion filenotify biblio biblio-download biblio-dissemin biblio-ieee biblio-hal biblio-dblp biblio-crossref biblio-arxiv timezone biblio-doi biblio-core url-queue hl-line parsebib bibtex org-ref-autoloads citeproc-autoloads queue-autoloads bibtex-completion-autoloads biblio-autoloads biblio-core-autoloads parsebib-autoloads avy-autoloads org2blog-autoloads writegood-mode-autoloads hydra-autoloads lv-autoloads htmlize-autoloads metaweblog metaweblog-autoloads xml-rpc xml-rpc-autoloads mediawiki-autoloads json-mode js c-ts-common treesit imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs json-mode-autoloads json-snatcher json-snatcher-autoloads password-store auth-source-pass password-store-autoloads page-break-lines page-break-lines-autoloads vterm bookmark tramp tramp-loaddefs trampver tramp-integration cus-edit pp files-x tramp-compat ls-lisp face-remap compile term disp-table ehelp vterm-module term/xterm xterm vterm-autoloads org-journal-autoloads deft-autoloads yaml-mode yaml-mode-autoloads emojify-autoloads spaceline-all-the-icons spaceline-all-the-icons-separators spaceline-all-the-icons-segments all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons memoize spaceline-all-the-icons-autoloads memoize-autoloads all-the-icons-autoloads spaceline powerline powerline-separators color powerline-themes spaceline-autoloads powerline-autoloads multiple-cursors-autoloads helm-git-grep-autoloads helm-autoloads popup-autoloads helm-core-autoloads async-autoloads ivy-autoloads python-mode-autoloads org-bullets-autoloads direnv diff-mode direnv-autoloads alert-autoloads log4e-autoloads gntp-autoloads flx-ido flx flx-ido-autoloads flx-autoloads xmlunicode-autoloads auto-compile auto-compile-autoloads js2-mode-autoloads string-inflection-autoloads org-mime org-mime-autoloads bbdb-autoloads loccur loccur-autoloads phpunit-autoloads yasnippet-snippets-autoloads yasnippet-snippets yasnippet yasnippet-autoloads company-autoloads php-mode-autoloads ghub-graphql gsexp ghub url-http url-gw nsm url-auth let-alist graphql graphql-autoloads treepy with-editor comp comp-cstr warnings transient edmacro kmacro gcmh gcmh-autoloads forge-autoloads yaml-autoloads markdown-mode-autoloads ghub-autoloads treepy-autoloads emacsql-sqlite-autoloads emacsql-autoloads closql-autoloads magit-autoloads magit-section-autoloads git-commit-autoloads with-editor-autoloads transient-autoloads sqlite3 sqlite3-api sqlite3-autoloads firestarter firestarter-autoloads editorconfig editorconfig-core editorconfig-core-handle editorconfig-fnmatch pcase editorconfig-autoloads f f-shortdoc s f-autoloads s-autoloads geben dbgp tree-widget geben-autoloads envrc inheritenv envrc-autoloads inheritenv-autoloads flycheck flycheck-autoloads let-alist-autoloads pkg-info-autoloads epl-autoloads spacemacs-dark-theme spacemacs-common spacemacs-common-autoloads compat compat-autoloads finder-inf ox-pandoc ht dash ox-org ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox ox-pandoc-autoloads ht-autoloads dash-autoloads org-crypt bind-key my-firestarter ob-ditaa ob-shell shell ob-dot whiteboard-theme server ido help-at-pt allout cus-load define org-duration org-clock advice windmove easy-mmode time org-agenda org-element org-persist xdg org-id avl-tree generator tabify appt gnus-icalendar org-capture org-refile org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete comint ansi-osc ansi-color ring org-list org-footnote org-faces org-entities noutline outline icons ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx org-fold org-fold-core org-keys oc org-loaddefs find-func org-version org-compat org-macs format-spec gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util url-parse auth-source json map url-vars gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int gnus-range message sendmail mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config mailabbrev mailheader gnus-win gnus nnheader gnus-util text-property-search time-date mail-utils range wid-edit mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr gmm-utils eieio byte-opt eieio-core icalendar diary-lib diary-loaddefs cal-menu calendar cal-loaddefs use-package-autoloads bind-key-autoloads info straight-autoloads cl-seq cl-extra help-mode straight subr-x cl-macs gv cl-loaddefs cl-lib bytecomp byte-compile rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads xwidget-internal dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 802052 442929) (symbols 48 54570 10) (strings 32 265826 103942) (string-bytes 1 8283120) (vectors 16 131683) (vector-slots 8 4350011 2882978) (floats 8 2108 2629) (intervals 56 1888 1441) (buffers 984 17)) --=20 http://hexmode.com/ I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me. -- Ralph Waldo Emerson From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 14 17:05:21 2023 Received: (at 61514) by debbugs.gnu.org; 14 Feb 2023 22:05:21 +0000 Received: from localhost ([127.0.0.1]:57250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS3QP-0001nZ-HX for submit@debbugs.gnu.org; Tue, 14 Feb 2023 17:05:21 -0500 Received: from heytings.org ([95.142.160.155]:57118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS3QN-0001nR-Pd for 61514@debbugs.gnu.org; Tue, 14 Feb 2023 17:05:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676412318; bh=6h2CjgKPLgsjCDzHOcO6c10ELbaSEntefobNN6fl1kM=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=zfrolKMvS8dN23Hcrzs0YAJ1PV9+ePHIRaWhAQboixq8h79wSUoXXrqPXq3frNaH9 72i5cu4F/dLwjmb1pv/ja/vK9RbuRvhpfYVqYitlaUKtiTNmEhT0z1IrJRwEr0wMhZ L7xCJOAP7f/G0MUzTbSeofaYx0rUch7yPF0/7G1gzZxp1xO2YcQJoV0A0GNcprkFcf RAqig4IAoJOml/+Bx7odUkwCbK27WaCXj6PD6S0zE8fC2DxEhnb+ECuJ+RDAeiQ+Mt gFmIXPaS2xVPKwDNQAkjKwuzRtCdEryf5b/kSDWszSK5GH+wpr9J7cE/sUJNQC+o/z lpQJyY6xVENEg== Date: Tue, 14 Feb 2023 22:05:17 +0000 From: Gregory Heytings To: "Mark A. Hershberger" Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <87lel0c65v.fsf@everybody.org> Message-ID: <0f053182b05e84d6251e@heytings.org> References: <87lel0c65v.fsf@everybody.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Thanks for your bug report, and for the detailed recipe! > > Bottom line: Emacs 30 is handling files with long lines worse than Emacs > 28. > You jump to a conclusion a bit too fast. It's not a bug in Emacs in general, it's a bug in nXML, and specifically in its fontification routines. Try the same recipe, but with fontification turned off: emacs -Q M-x global-font-lock-mode C-x C-f a.xml and you'll see that Emacs opens that file just fine, and that you can edit it normally. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 14 20:07:11 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 01:07:11 +0000 Received: from localhost ([127.0.0.1]:57418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS6GN-0000Xl-9J for submit@debbugs.gnu.org; Tue, 14 Feb 2023 20:07:11 -0500 Received: from spam2.m5hosting.com ([206.71.179.218]:46640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pS6GL-0000Xd-Pq for 61514@debbugs.gnu.org; Tue, 14 Feb 2023 20:07:10 -0500 Received: from mail.nichework.com ([108.161.151.158]) by spam2.m5hosting.com with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pS6G5-0001af-UP; Tue, 14 Feb 2023 17:07:08 -0800 Received: from mail.nichework.com (localhost [127.0.0.1]) by mail.nichework.com (Postfix) with ESMTPS id 53CDB4E00B6; Tue, 14 Feb 2023 17:06:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nichework.com (Postfix) with ESMTP id 2E11A4E04AB; Tue, 14 Feb 2023 17:06:52 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.nichework.com 2E11A4E04AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=everybody.org; s=C75414D8-59CA-11EA-A864-6C07A2A44C35; t=1676423212; bh=5ZCh5oyd32Sa+Un1tBcLIA/Ei9JcYxhoShU4mGsyXTU=; h=Message-ID:From:To:Date:MIME-Version; b=K5Z3WTH/vhiy+erE14iJI99jcB117SOZZ8jgT+hNdJI914UMu4+mxg0aIG3/tNBwy 8ltPbBQzUBnzPOZcOxjRtIX4mAdUVJxjzPlzGrKXu85y6QkiUDjCRSI10pLg5F2dyg 0TqIlP4lrMcrlSa4x42lDa0IyvyPznBajUzuqPF9JA6uyiPl6i8f0uQSUJtY8L2DNB XEUxW3mAogiQq6FGw0/vKqM0pPcqF8Py5NyjZrwosNtyVvPRfYRXJb12NJpwMbiDOr 1oJVj7bihhzVRKeqgRCtr2HH/A7+5ave9SHgSl9o0BKc4oNJyTvL/CR51gtboqxVjG dAcIVDyElT9VA== Received: from mail.nichework.com ([127.0.0.1]) by localhost (mail.nichework.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uHSpa-KKdKfF; Tue, 14 Feb 2023 17:06:52 -0800 (PST) Received: from [192.168.77.100] (209-253-11-93.ip.mcleodusa.net [209.253.11.93]) by mail.nichework.com (Postfix) with ESMTPSA id C6B524E00B6; Tue, 14 Feb 2023 17:06:51 -0800 (PST) Message-ID: <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs From: "Mark A. Hershberger" To: Gregory Heytings Date: Tue, 14 Feb 2023 20:04:46 -0500 In-Reply-To: <0f053182b05e84d6251e@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.3-1 MIME-Version: 1.0 X-Originating-IP: 108.161.151.158 X-SpamExperts-Domain: out.m5hosting.com X-SpamExperts-Username: 108.161.151.158 Authentication-Results: m5hosting.com; auth=pass smtp.auth=108.161.151.158@out.m5hosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zoC4Sd6MuPGeS+nH6FJ1zAq4GtIDuMhFE7WdS1kORfBmVx YTLDjObNJJaW7uo6sk8giifvPJN7o5v5p11VZDvDLK2XfTlUFb8U35eqleIzO3iaS8Y2jxxNQPzs mflfncQvbNw4CjuEHVMXhgAJ5qdA+fFJpb2StL4JHf5Re+IRHKyRDmWTqFkCTa+hOsd6bFab1S+M Qq/XNnT9NfN836axNaD8OEntMpgwfD0OXe0YRwHXl4wgwTqJlTT/fetzilMGV02hzj+6Clu59u5s r7HikapUBPW9YV4SESdWyVtFdVGH7sydZvDt9c5R0PA8ODZKD9oaygXSCN/J/iP0aMzt4BUv8mER Bx5vH1dl0t5WgfKaz7sqUIvPu4gg9ArNodeU/86+VeHQfEPfz3YUMMqBqSIGAS5g6SocktP6HR2V 1PeUZuqQCoVLwZyYlc8INfciCLCi02+wdo+09dJvN9k42Wq2InZGQXRwgp4DivepysN6jYX/nXkL yQnRCh0nB+uYUazmWajDqA7NT8Js52zSASJFC/49WOPBr5nlEUI4xKJflYtolNE/gpASosD6ONd2 ufTFucIGU68mxJgqYl36pcZIGMM+XCijokhnNr3Nl7ZnuAD1Ds+KvuxXJpuUX7i9V5NY9eQuzhCd ek+2mQG5f3aLyhZs3zeqo/pz+kFsM4sEMysPur9wmiDBurOy6iSi4e9MWffGBAuvamEecvJfWG2E RdZG5Rh407j5wGYfUQiVEp7HQsv5pLeDas9tL1xCUrz3fMD+vazpt8/j46ZVbLzQ9rMYGFaZaGZs j3e0MPqVH4M6PLUISnc3cpxaK5vDqcigOvSxdRnthmhn8Zn6fXak9TvFCYwkMZsmGNxj4GlxTX22 qx8BZ0KzVu30gX7H+zDkQ7jS7LzT5nC5H0QQVXcPnHrrpXiMg7WryJRjWY9yYjkgur7cbmMvzASy KBHx6Dwy511VF2c2erOLgBTPqDNKToL2xQmqr15vNQO8SQ== X-Report-Abuse-To: spam@spam1.m5hosting.com X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, 2023-02-14 at 22:05 +0000, Gregory Heytings wrote: > You jump to a conclusion a bit too fast.=C2=A0 It's not a bug in Emacs in= =20 > general, it's a bug in nXML, and specifically in its fontification=20 > routines.=C2=A0 Try the same recipe, but with fontification turned off: >=20 > emacs -Q > M-x global-font-lock-mode > C-x C-f a.xml The bug is not (only) in nXML. If I run =3Demacs30 -Q=3D but alter the load path to use emacs28's nxml, it still hangs when I try to load the file with the long line. (Yes, this is a silly way to test if the bug is in nxml itself, but it was the quickest I could come up with.) In =3Demacs28 -Q=3D, when I try to load file, I see various errors, but it still load the file and I can edit it. Perhaps the bug is in fontification. Perhaps the bug is in how emacs handles whatever errors it is encountering when loading the file. The point is that whether it is a bug in emacs "in general", in nXML, or in glibc. The point is that there is a regression in how emacs behaves when loading this file with long lines. It "worked" better in Emacs28. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 03:39:55 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 08:39:55 +0000 Received: from localhost ([127.0.0.1]:57680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSDKV-00045j-1V for submit@debbugs.gnu.org; Wed, 15 Feb 2023 03:39:55 -0500 Received: from heytings.org ([95.142.160.155]:57660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSDKT-00045Z-0z for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 03:39:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676450391; bh=CZ7VPDFnePZ9w8u+arc/ylCwLhWLmKMchLr2la6rfVw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=19JpqZPGdFE3TVRJWeiR0lXL54jaggpcSUXjeFUKvWF4IHjVXuwp+aapciLvK8O/J ZVxUnVBcIgUtw/4EuBj+NDwrPiufbVxJGLjo92KWgvv0s4XVfHjdvmNsmZ1oMur9iq S+ziJoYEq52bBDmVtNc735cMjt8XtyQ9bgy0+0CsdWOBKf73/6XqsGvV6h8LYJMhO+ jw3ZJ36ro0U2niL9cT2agU+r+nt9mvOIF0gln+mwFTbOIQKatLHxDHN3qszBwMrEzC Robg/BnGRdKRwCs/owQzJkuPdmTK+Nu5tA7EBP0+cLc7DDE3vDUFBuI/Y1Rt4JaMxV 2M8vP6KceDaRw== Date: Wed, 15 Feb 2023 08:39:51 +0000 From: Gregory Heytings To: "Mark A. Hershberger" Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> Message-ID: <9e9ed8043f6ceff84cfc@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-ID: <9e9ed8043f4b7e9e4cff@heytings.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > In =emacs28 -Q=, when I try to load file, I see various errors, but it > still load the file and I can edit it. > Did you actually try to edit it? Not just typing "abc" at the beginning of the line, but (as is described on the web page you pointed to) moving to the end of the line and performing editing operations there. > > The point is that whether it is a bug in emacs "in general", in nXML, or > in glibc. The point is that there is a regression in how emacs behaves > when loading this file with long lines. > Nobody is saying that there is no bug here. I was only pointing out that the bug is not "in Emacs", it is in the fontification routines of a specific mode. If you turn fontification off, you will see that Emacs 30 behaves much better than Emacs 28. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 05:26:34 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 10:26:34 +0000 Received: from localhost ([127.0.0.1]:57892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSEzi-000753-4H for submit@debbugs.gnu.org; Wed, 15 Feb 2023 05:26:34 -0500 Received: from sonic316-49.consmr.mail.ne1.yahoo.com ([66.163.187.175]:35330) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSEzf-00074k-9l for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 05:26:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676456784; bh=BbPo7UHj8eBFQaQd8FBK2XiAjbBGgbVIRD+iyPXWssY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=GaY5acxagxeAdszgB+sgYs/kn6YRNcXWEam+dE9zEWjZxAuZnducED1yu0SaKP0FDM4iJYxyD3yPUtSonT8qHiMcvM7WBolMDbjYV0MqgvBEZ9Gs1Q+VHBTJmRcP62Zy3huQNtXQQJ2RK7PoFegWoLDE8APuGXMLdpncJqHi+svxvUPGtAXkpXcCRjvvbdpufVyl0JPqYInbPa4VX0LEHKJgWVdzwkF+UW9GUPSi64Qu0w4uV1dGtm4pYYHMqofvhwhPu3P1W9cEsdjQdq/xdJi40nIolTf91n7KI+qWoyKfIqOspjPGn38ctW9wKyN4cyQUhvrHLI+ogMCh4UnG9A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676456784; bh=kam1yzrl1y/HiAnRkd9m64YnQDkR5dDTCXx8qaV6ZM0=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=bRmhuBY8DkvqVitKGZN1dfpsP1BiboIGk5GOITHS8A+fM3PC4Do5gcmkkuzFTazBD13ZA59AZFsEFt2yd1Sbr/I4TFLNf466FH7Ok7RpCwzgAHE8E7uq2yvfNNxJMgrYjA18Nq9t8LhSSu2AGbgqHWMbog7QI+lm/zV2kpe41cDl48NfJeE56yIfz594u0Au2vBBCEiyc9obe/rf/j5tJRD8saeH9775gXVodNnnnOWlIPST2RFfm0ydUflEFVn8DN6rYSiwq7rkJWqTn9fqj4AHYmhF4N3HyNHl83fV+v2Dj7WF4xucqCKSsE6oJM5Kd9WtcODZ8fTkIfJztLxbow== X-YMail-OSG: UfDorIYVM1n_KAziZpYU.0P9_FfPPMBCruj9Gnq.PSMov907Q9kKIC07VaUyZ72 pnYO7SjmVIvxxBs0Nb9f9sbFeDN3gHt.YdKWbLU7MRoeDkPcPw8JC2k27tHR4nJegjKQrk_5H3P5 Mo5Kse2n1gDJv3qerv7pe.jgI0wmjk9iUZownKi0Nf0v5c_.GiZGz6NAdSdsRhwn.b0KZY_WYAxl lt4Vz_0K1QXfR1FuACTRNKH5GPsYQft1I194aSk3UTrzSf42.GxpO3o_ZNk6Tuh1turmZkHgIhp0 yOK9.HMi8xwTCLBQRrwnwWlkGq14hmmJR1Cy9NLS3QEykAAbcCvSQVNNtPgBZS1v5J_s4_hhr41u irBUr5diMY_jQPh_yETkYJYo9U6KmYfFKUCB52TQ8nsOKqXzO52t7lj90IG2bXPCp4FZ906yEkUB _CSj_rnF8J2HPkhWqCl9Ns8xuigPQ8yn0NwiGCPLOqmDykbpUqLynWMXUc8W3inzcAYbVpDxj3J7 eyqS90xpmGmcf6tpneD4Y4MCQzkJnyGThkarEBzN2hGkDyIWAk_8xXgFRAd7mySIaNKLal1o1Emd 6D6oga7scZA7tJDC9AiSJiqS3BLBD82Dzva2GptRRGP9N5z7Lrfcvvo651laGj.VeIQQ3tlA_Amy vEyTKXppfWiIIPOQXkTz2laO1_JnyBLldFZYc9z.VqYYt0YzavvZOt9pHM.9pa3sPGY7KjZfxF.Z VvvRa_Kl0fRZfCoTy5LYFr9RrCSA3WdGmRW.ndJlam2hU22GYe1__HiOiCLeAIVIdOtTC0rTbTbf y5TCmTYohvGC2NviyzzI.bYT3hXvc3kpl2gT0wJ_7upFCdC8BSt00L_F25gkPw_j9PEQM3vPi_Bi O2Lk2g7Y6iu6nhVqQecxMzpwoGSaOOweIuJMy4d8Qe7a0zHWX9huvgNlvwX6ToSXRzojZLQQ.YGG pu.xe1xu.cLyh03vzHeeEH7abDSxd8TtAX96g5RZzPXzQhkiejf4tQ9D.9w4mNSFW04jnMoZUfzS it0s6SCjgE3I5yB39JLBK5TLnTPjtVVWKeSaXfgxDJPKrAArRoPDHS.mAS9s_GzRs5luJsLKKW1_ RTaFx5lYnE94kTe_nC7kzUPHmyi5wiRQVsTFHy6z7TfPLXELIogOii7rTafyRQfqUsN613t4x8rl wELhlQNa4Nt9VYE_6bTN7ZD9CWSw7jY2kuz2dqN1jPiWSRXgF4Gp6rljuV.s.nJTBCpqhTrbjeZ2 eqxWQ86.oXN6z.XX6pWW4ZC1itMWxEWZM1KUv8mSinC_4qt2teno8mFtIzGEmQ4I5Z_3Xhn63Qs0 oOott4mTz_qNcI9vzNQicS09XQkgHUistwdj5PJJWLMjAHhqc0F0vs9GFwY.Z1poHBbWfQdNerx6 Uq0L2fzu4DwcGgEjb6Vjt0BgVm_q5z70In3CJ6MT.fneFSFv4MVRIs9pknAk0fRWO_wZcl4H1Vax gWwAGzcABN82e_8jcYGoDOco3BWxCVH2ib4wpGNhpGHW4.aFSgegu0Gug0dAbjOA5jDEyoBumdaN oATVSA4ZI21mGLwREE5znGeyN6ATXYkMpmRTf.yHDkm1_CDAyJWu0Cmo.1wsL6S2xJtKDA2Kn30c rwElOm_yZixuSx.uNcyHNb5EApWgHjpcqYGOm1IlyL.MwsfC76P5ogFkgxoS6nqjgbxasMa816pg zBGqgue8WmsxYarlLqkvQHu.o7FlzYX4rWzhia2FY6UZGqw6UXBCwPvnSA2ekVl6ZR6aAdEp_Nk9 l8h9NbWvNfWj.8CFfTS2kjQztyKsU9_9PUq0BabEnohiadYOcKRCLF3eDYUTtmqQ34RI.N4qTUm8 5S6abwrPPZCwW3AcUk3r1xZdBW_Lfq9O4vrW1rWCZc2GsmV5BgcdkCS9aLvMsm13TXak5iSM3NGA fx.o3p86XeC_JwPCVQfXqr5LLTOTnqaDAO7VBHlDMdIGhx30ouCh.LVKmuqVpb6Oy8qcy.QRbDnt jy1LFGBfUcpegLgjMX2M_zcaT32yru3vGpB4m9ifKt7Q93Sq.ZzLuInXAAbpRQ7xBCzhY751cptJ hOJcMItw0_hT3dAkRyXYro9WYz83J4OaPuw_lAjhj8_DmUFr5Z8EKJIiCLzaJseh8FVg3ZdzbBPE PPH5rT9VobLRVRPKwmPV9thbt0Srr4S3yHdDXkpL0P8c.nE5aiBv0MgOi7sUK0H.zEju8xSt4n1a o4Dsqj7yiERNy_Cr_NvR1BP8HN4ctwEedx.r2YnUbSoPl7HKdjX.U04PTVYgwyrw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Wed, 15 Feb 2023 10:26:24 +0000 Received: by hermes--production-sg3-9fc5746c8-r2vxw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID abbd45cc9fc8e453205eba9dbc511d2f; Wed, 15 Feb 2023 10:24:22 +0000 (UTC) From: Po Lu To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <9e9ed8043f6ceff84cfc@heytings.org> (Gregory Heytings's message of "Wed, 15 Feb 2023 08:39:51 +0000") References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> Date: Wed, 15 Feb 2023 18:24:03 +0800 Message-ID: <87h6vntef0.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21183 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 367 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gregory Heytings writes: > Nobody is saying that there is no bug here. I was only pointing out > that the bug is not "in Emacs", it is in the fontification routines of > a specific mode. If you turn fontification off, you will see that > Emacs 30 behaves much better than Emacs 28. And when that mode is part of Emacs, the bug is in Emacs. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 05:41:11 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 10:41:12 +0000 Received: from localhost ([127.0.0.1]:57900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSFDr-0007Sj-LO for submit@debbugs.gnu.org; Wed, 15 Feb 2023 05:41:11 -0500 Received: from heytings.org ([95.142.160.155]:57776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSFDm-0007SX-8w for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 05:41:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676457664; bh=d6g52Mqlo6jFQkNYL1YLd+Emt3LU6qxYP66QMIJtbLU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=cFgsfSxd6am3cypJ/xuexe0qIvX5/myyXn2uXn14ToZwPyeud7yJHBJOOb4CvB7DV TClWVBF6onLtz9SbVgk+k4WYkFjems1TqbhvaJNLeBGluS9XdvC2IeWqjFkWyB6RPe YBZYw74fLxm7ZAQkcLSWI5T13ZqnuGdEIv/KmTqoDOGIHYTq7WXYSASlQTP0XmNsV6 9WHBgGxYHMsr8GD5PYY+TPm+B2UPdCAOIY0iMvpNW68G0OWemERIM5RUpC6bdxbLPV pzGC3+/2U+efxXTHN59gCi1rnkoBz1Z9HC9TpKoEVZmBVniCUsJXe2U4TBZ+lqIwLn 1f8PwRUUBdqdQ== Date: Wed, 15 Feb 2023 10:41:04 +0000 From: Gregory Heytings To: Po Lu Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <87h6vntef0.fsf@yahoo.com> Message-ID: <9e9ed8043f2db866e3ba@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> Nobody is saying that there is no bug here. I was only pointing out >> that the bug is not "in Emacs", it is in the fontification routines of >> a specific mode. If you turn fontification off, you will see that >> Emacs 30 behaves much better than Emacs 28. > > And when that mode is part of Emacs, the bug is in Emacs. > That remark misses the context and the point. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 05:55:01 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 10:55:01 +0000 Received: from localhost ([127.0.0.1]:57943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSFRE-0007tM-O0 for submit@debbugs.gnu.org; Wed, 15 Feb 2023 05:55:00 -0500 Received: from sonic302-48.consmr.mail.ne1.yahoo.com ([66.163.186.174]:43184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSFRC-0007t7-50 for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 05:54:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676458491; bh=I9tQPcAcw432UcJF2c0NZmhfIAO5VNYpOZu0FAoASYA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=Nq0ZmeMq399osNecBnlsx4Y+YLpqxkLsmd1TDzQstKefNf54mb92Nru/uIqcQbM1UEtY3jzn4OOPDl4/Oohwjvg3B891ptFVkOB9cxdDmGvKfLkP3xJPy2esjmh5JFCnTdAEz7+jkd7JlSdAarqZN0buWCJxQkjsabsyP8YnwiO6ONNjiFEbkznnwfI9iF6uEBPxUOvxo1m5h68k77pjhMNpLNN7x8II5JlVm8WriEmpPMZLy5wKBVsm9JM6TsFJatsLaYDp2XT45bDi5tCh6nZ1ClS3b4wZkAlFFenU3P+DGFnPJPk5bqJeEo2XSHzESG/gJrJcHxi76oVJHbwSBw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676458491; bh=v5o82H5KcEv/Mbh2Cj6vg6UBLMUaka2qAqI4vMgmoPK=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=iI2zXn5X3xlObBkh1AauNrqHFzKmXVgdQy1Iwm4naa6k08MmgMny8F6qrnjozWb4hPQHohQsiWBrF4Xr7FYwn4GnCzrECRP3OS8WZGfc0DIjgWIlHLVTSihEFzLqc+kKGcLaFfofa4vFmDyM6Aatdtyr+SXTCw3MT7ipkRWOg0ZxqIgIRnMfu0pRoegjjfkN8GhpIT25nukMDfvS7TfXSXAg0V9LAiWZ3+nw1aBPpfINlEDPMq5pJlQ8fPrMe+ujfQsNvaW7QCkUhxvq9kjoQr4GtDczCN/LxosP/OsdMRQZAWzd5zzyL4wtL44YkCfDv4/5N3vGNNBXCcbNgW9SnQ== X-YMail-OSG: l27tWyoVM1lFDOA04rWDqT9rpNoiLuX0QbWWwRhNbyaILXvYryNBthPHmzvSZRn D2xbH7CphU8rBgHT8gJF3lnEQ5ax5vfQRDB4YYN2m6N6pnw0qCCPw_FgW8QWngg3W75bM0ISphAP AhPzrsgutnEIIXIxd3e6SGUAarU3Cg4wQNVE8WXYvWoDuG1kXnKWr6kj4LizLjrIaJB5dali5sVd OUDmHYZ4t2JNQNAx6WmfQtqhLV5W5bhnenu622ceZf5KGJShmDaEil2_26arV5OQzkcOPmEFMgCN gLn3gc25MWNSNf3kVn_DethkZnU1IL1iHsmHNh0IMv35JAGIgod3cmXLMYsxL0cVMbKkTQXQmNDy YoJspkDVCqQY_CVBB2Wqcx6ctH8tEUPMXNudUcJwaTgjw8oOXPfYwlXqDqxmSGCH_J_7_dQbObAd S__vC.YdLRBuaag.pxYHV6Qw8ehRP5qRjGdUsZT4P8Vfm66ZtnpQcJBhOKs.6lGJiz6v9M3OEiRM Y5F48FnOFdzi3i8RSnEPzEiW2wL.P8bg6HBA.JbDA..tICZ1andpZoAYofmnRIOiXqex9rsJE.Mu kw3J9GS5fsjxQjDQxagzsWzNbTHbgVc5ZmTicxs.WyXgZWDdst9x7Du.dFy0LKc4U8jlvFYq0Acj PMT9Bu24xC2HDCgRAVaeqZOr9e5GCxIxY3vSvB_Kxg3OopIstTMuWep7cDO.BJv2hVfvLvBaPMe8 GuVi3BvBwtrG4VQl2E7V3qd_Vu6qZU45St3ghDA6Tep2lFkozA4mr3gW7AlWhLgLMBd1GlhLFqvW l88.LlcGkz42NJPn22n0lro_PJzFs5AMEjSnBw_JoWQShqoatfTFsogydgnJhGPR.1NuuLO2iBo. XF1p7owSGGwdy0NxYqorB_eBaTo_ETW5mBIeGuC2s458.i5BL75LDAWFl9RePzTYUBUYgMjAeL7V 6nLGMzEAUPiy6o_okcLj6dlbhLPrPLKY_TbGn6zPGOHPhcnOQ_pu1Yiw9DIEHRI7v_fKmaS4Ze6q V_SlO67BIAJwrA5ND5lezCHpxjUonlvi57ScXuV3VxeaZEyDE67sYvggqXj8SQMUoDl7.0b7cPmZ MT66Y70YKKsoAZoIwPmiQoPZRlIdHq.GXw6cvbmpukL6AY5W_NfwPZ0ySvamI3OWOfVQYbIPjeQn 2v2rJulMB.9PrySDk9T2dzkbxRHGoZkZTp6l3E.teHdkQ21ODCY17bKOerlHRBSfvCn2TLw.JBmn cilwdXalwQjUqWFHxOVcuUZY5DTkdQCh9Ievn1FqeXpNjPdet_xW6hjnyXVpk57GQ31TsS4x3DSN aF1gBGJKjVLEdLpx6NV9CuHJcWLeIlsDZKmoQ_8iwV7O.tDF.ByxehEu4DCw3XyvOVm87RQedIse b1yPPBD3QCc7_I6eejRQIuHgmuiy00UyQr3jC0BgKjvhZfvhx4dzzxfaYFVFe3Soa4vuyjwgMEcH EtmNExcqGe4b5GB09bW1A1hl7hmICFha4Cl1YHGx3Ef4vNllPNe0g46QDLXDwZ5PXVrHF5Lpw5xk 4cGtbLCJHHi.KcAznx4VU2hub4VrueWYHOD_ohDbm66KArdMhVAOTKbF2CsMh7361MwTY5Q1JnUn igp1IbP1Ih5l8AuPDPTPsC8TKWRiwXLoRhSTsF.1_yS6PQ4ZcWRWk2O7oj0C__4Fcw5Y48Q68_pi z6JkByIZqXkeaFIcclsjMbNbwPybg2WMMFD0_YzPe9AK5jqW8P6ZDpZSKhh.HrXkfluBZ0dp.zfy uk9V4ILPF4r4pQMBqOpiYFuS.a9PYFMfbeW0Fw0AxJHSyQQ070npff5nnzODCxqIygFfS6MdAgXA cGMvScxRD7Oa1b2YFMXUbVuUnn9XqL4l.FLsyP39RRoILAbROILdbdVGIz.CU5BMsn3AO97BzZ8u 2MhDXJGMi03b_7FwlZvrsHpcGJ0JLAop_EBII1W086Zq35SbYlkOCs6b93Fzmj1AuTs9DlNJ3IbJ hK4cjmyaG1qnwHQQgwmPDGg1IRspU6glU.UMb9wezmJBcqbOSM_Cy6EAMpoH1wAMRIeG1_F7_f0E zDSInELyUkRV_.HQsGFn2ly69ndC9sHmvNI8awmDNAGdyJB1WCgyE._3Xp1XFBZ4_1k_Iw1IZJhJ nvWgMLF05tAN53t61BxccZTqRlEC7qVihIszlVZifvja_tov991GChXpWS0obGbUcxdEfGIFxFjv MJ4sPpOjeznP.DlPuDtM.KmR6VXGSx7Yb5YxfctTBU6vKmzV8CmIPriPmpspGF3o- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Wed, 15 Feb 2023 10:54:51 +0000 Received: by hermes--production-sg3-9fc5746c8-7wpmf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b4924b3b70f94956a51cef25b08039f1; Wed, 15 Feb 2023 10:52:48 +0000 (UTC) From: Po Lu To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <9e9ed8043f2db866e3ba@heytings.org> (Gregory Heytings's message of "Wed, 15 Feb 2023 10:41:04 +0000") References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> <9e9ed8043f2db866e3ba@heytings.org> Date: Wed, 15 Feb 2023 18:52:25 +0800 Message-ID: <87cz6btd3q.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21183 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 574 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gregory Heytings writes: >>> Nobody is saying that there is no bug here. I was only pointing >>> out that the bug is not "in Emacs", it is in the fontification >>> routines of a specific mode. If you turn fontification off, you >>> will see that Emacs 30 behaves much better than Emacs 28. >> >> And when that mode is part of Emacs, the bug is in Emacs. >> > > That remark misses the context and the point. The context is that you dismissed a bug in nxml because it cannot be reproduced in fundamental-mode. At least, that's what Mark will feel. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 06:00:04 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 11:00:04 +0000 Received: from localhost ([127.0.0.1]:57957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSFW8-00082J-C1 for submit@debbugs.gnu.org; Wed, 15 Feb 2023 06:00:04 -0500 Received: from heytings.org ([95.142.160.155]:57798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSFW5-00081J-DL for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 06:00:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676458800; bh=NvpZ/kIdaTQAmmtGcfK3fnKZur4e3nG1/lEBHho+aTg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=TlL1clMj7rhTCGHrfgY7St09iCg4rTG7rGi76fXku64zIIWErivhFrEFWMX3j0a7R 3nQWUBYlSDnDBHBcIojVdvnrM7upuKT0FBEJbBOYb9ZFYbNRCSTIMgO0Tv/w7OJoHz eOHLrR6JrLbKPEx7Q9HlHQGxRPYMOhQ3Iud/AF0g4AEFzs1iDIm7g7dQ/fcHsX6dTT oTeNnbKU2lHbV5zvTNjqzT320U9cdp1IG7tdZqDP7wLyFyirtbMunL3wFaJkF5b4uX AB5tMhk82jYvDOuzHNxrOiygwMbnA0BNiaiouiD8dbZNbc6b43e8dlTJP1Nw1FI9ot BfACA/vzDshXQ== Date: Wed, 15 Feb 2023 10:59:59 +0000 From: Gregory Heytings To: Po Lu Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <87cz6btd3q.fsf@yahoo.com> Message-ID: <9e9ed8043f2342b86537@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> <9e9ed8043f2db866e3ba@heytings.org> <87cz6btd3q.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>> Nobody is saying that there is no bug here. I was only pointing out >>>> that the bug is not "in Emacs", it is in the fontification routines >>>> of a specific mode. If you turn fontification off, you will see that >>>> Emacs 30 behaves much better than Emacs 28. >>> >>> And when that mode is part of Emacs, the bug is in Emacs. >> >> That remark misses the context and the point. > > The context is that you dismissed a bug in nxml because it cannot be > reproduced in fundamental-mode. > That's not the context, no. Nor did I dismiss a bug, read the first sentence above: "Nobody is saying that there is no bug here." Nor did fundamental-mode play any role whatsoever in this discussion. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 06:54:47 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 11:54:48 +0000 Received: from localhost ([127.0.0.1]:58046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSGN5-0001FG-HU for submit@debbugs.gnu.org; Wed, 15 Feb 2023 06:54:47 -0500 Received: from sonic303-48.consmr.mail.ne1.yahoo.com ([66.163.188.174]:39532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSGN1-0001Ez-M5 for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 06:54:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676462075; bh=xKjqjNK+uGW4SbyxTRiWOLSrtYWQo+4coTL52L921NQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=ZfMHFsy58D/kn7PUN6hLUGXVzfan6Us4/vtnMpwpSic/PitAY5nCBydWrvrX32HqeoqExQdz1nO1/tMoIz8NfpgYqBhJWySsZc0vfGIXIkwP4MRltu4wjWWGgLWQk8Jm9GM/oE0Y2oHxKhzTqDGJcuyJQd+gNffVuvm/GRsnZTMA8E+FVxTR6psIsG1Fb3VcLtcJH6Gr1BY1ItK23bAw0KW2jldSPbExCNsi9ObTzVBxSsYL/6/AfYx97mqv/MRdvI34sC8H0ugVoGYJXnWGJk/JwLspfY4pnNxdAFLTpS9v0CGweqlPbBGALXbd+HSOkSzqU3i6aSbq1xxeFeK9Mw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676462075; bh=OrKSwEAgroIcRn478rBsM1adUSTRatvoCY2OBMWtQL6=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=GbPw58cDkhOm5w8M16stXhtn/t2aiWbmqn8L+/aVb6zQNyC0/5Y1OzTLdKDs/EQ+YWM/gZScWFQyRIUgrDOvds4ysapKStVZaO6aSWdmTo74HiY228ofMAB/gee9uMEBGto+xueAaeowBhzWqHhOHmDy1jMwdfg4CoTWNpBjq2RXpRghq2grZ5JXavoNyAu1hCMQwylXjhRa1f/fBT23xlj0rIzfBN6HHVGcTcZGeCeY84WVfVX+ZMtWvGf1kmPhLbNH75PyYheb5MCANsnLLSF89KKkZKBMEgQiyITjW4U9w0OJlEgL/ZVqkN1zv4HMCYCIvFCDgxbnD7ENXbSwlA== X-YMail-OSG: pJ8fefwVM1kZe.NTE.w74Go2JvqzPLDnyM6Vztpb0xPMFdMcyNxZkeNGzg78bXQ 8ozo1KAetKZ95dYTZrLDJ.r2tJBt7LZPvdqgSKUapd2NAQ2xM8TjDGVWNRigf9Upkl57s10mhocz ZJ.sQYJxQGDT_pSwtNbnFPQbYcCJN1xQ2gn8i4aj4vaZFUyifCddxOwxhdytFd7812cCTyEItSAl Z1RyEW..4B_5cNpaUGaGmRMeGyrWOU692hs93sVN1VdDKO_OolDT8HF2CbuY2gRoJDLuItkknGxa mcw35KkwgKB2PMHiPYXBqwJZfXlBkmMZPXQvkxTEN4KET2vHWsrostgL.aq6XMCnqV2X44TzeDmx EQkLT0ubj0etwSlF_5plOj3G67hcO7PfcqnyUBW3Opo8ER4eE6eTY0Wl3DyK_zMytIQPk4oE10MA 3DpagTfAw6ErfckbX7luHrtC0wh8ihQpaunzzDjNQIGwZoW37BhPMZgGzWEMGaFcgMXWYBoyEA4u lUxn7zYLXvTvJFK5tMRNmUMbyHwmp1qKEYbiEboOwylD43d01FiOtY0Qj4bO6jqYzNl06mozQ9ua oE6l5Vovd3GJQu.kKz1DrZq1nRijTPVPbWHPY5GaxKiuKMQroilnxcVIsRD3HJP8nwk0uZvVJAqH OCX5NqeOKxlDuiar2uO.12Dab.V09z2AJicF3yY2LMIwYb_QpjENXfxopkfRbt_cbrOb1mB25HEz 1igXGjIIcy9FWuLb0bMzjI5RbFW.r6zXiRr.GAwQT68Vo12yIuKrmf65lYcAwliMMLpOcETrxwip fqjxpFErLTYDhb48ymIXvoCtNxFl.1NBE9ZKz0Lce.qAi3TnLnkOLtW3myX3OsJTBhwVBdbzE_tL 8ri0M_EOGaGczZPsqDHg4KHoFGrPnVDvKU3joC3aDDqs2X0.bo0dUMU0nozANI6WH5jZBSIHPlwA E0Ry79FYpUfAerRnbuOMMP0U7B4smBXiz3.KxXAHHb4ZBdiQFwgjS2vt2lqFogk.7QA4vpr01kG1 0am4JKjnV.fXxupQWbQpALfB5hFG4fFwaCuB2U0ZJi1NplTSizuiFT1b.MVnQOQKALjg9JcvcvrI Mvo5ipAQvtmSchO5VClDGGES_kj9lNpK_Jt_SJPR7zgKbqf3zAs0XUyzBU4jhIZpCheGUPhUvByJ rCDLPoRw..znVxMWuFzK1OVZrz3Scucu..dzVDxMc6d5RPIjZCD7j9OLuLqS8zDTZ3PvxiKlHnbf gnSUG5QJEJ.rMLsG.uXMfT7pr_bFiF863k2mBWFrbNaUJqYY1XRD2DJ1Pk7gW94QGJue11dybpY8 oKoVFasVbhV04PehDwaxGJwg05uYJqx28Z3Jm4CVA2OmsERM8Xoir2HpAIsxrWc9HEkVrZVnvk4o w_ptnao.mK5yBxPT3SooyCXLzEP8ziABpgqD2c_WLRneLPCLbU0vxAYUbiql0_IZ5vLpkHC...0x nRmQ3tQTszwYIPEz9ey3wbhN1mxKAhN9NM6quWjSyYEWEJcDk7TicbbNP06Iq_C2ESgN3mG2wqvb jfbezaXdA1ShjWYYDMXPLWHL.ijeCWo2GTgEnwaxVHSasJEDBrsFBpD6xkYKk4gvqPLi1cdFqnwz Ocyz2z34l9vrX6TxpCfuw60KoTVXq5t6Qo15r_xfAeE2mvtkMR8pQxTTfgH.6Qq9PEKa0GI6NIIs grC6XAS0XnB7xBwLS1ngSRsY5Jqx7Gh_K5E1T7JFHLRC2OB.cH0FMetc6EMj7WE.ch6Qh14tIm51 SktZNSD5i259TWZGmx6O42W8h1_EmKOHUeKHHVot7AlNjRmoBlPsHhMuM.bdoeOxyxkcdhN8J53t cOIRE7afQ3MvgtyftfQLsQVtPvWEONdQFFUJggFlxpJN8ocDxKSYdqvlBAW8dHJXd3uAOnXvjfuZ f59Oy49MOxl84V1a9lKJNhp21xMKyrq7k3ptQcKyQdiQlyQwWVM5y8wodHdnPSX_FG4N4kuWWs85 s6P2T3gcVZnIOt7NLLBUgT6o0pI0VCU3Mh0nCfim.MYglkiYeNzD8xAkihZNYXwZWNsYf4x149aF wsmaha52tMfiHZaCm6YddH36aUBn3KZZ7IM_XkOIyAdfUGT_lxpbT8FUrLb.jaEaYngnqIP7g6wt dTjVd4OwPk2jUh73MgzGYQKdjTb_Mgz_RvrhJNaLHGKwd4D79zuBE_.fHNlfD1JnlnI7Q40OZvYv N6fLRAxFQBXsRUtZxDz2dHb6cJ_gkLz23LwEFLokKzfh84N.lGmL3tpn.WCA.1jHpfJk- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Wed, 15 Feb 2023 11:54:35 +0000 Received: by hermes--production-sg3-9fc5746c8-vmkgs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID db613cbb8625bb2bfd11be7df20a0159; Wed, 15 Feb 2023 11:52:33 +0000 (UTC) From: Po Lu To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <9e9ed8043f2342b86537@heytings.org> (Gregory Heytings's message of "Wed, 15 Feb 2023 10:59:59 +0000") References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> <9e9ed8043f2db866e3ba@heytings.org> <87cz6btd3q.fsf@yahoo.com> <9e9ed8043f2342b86537@heytings.org> Date: Wed, 15 Feb 2023 19:52:09 +0800 Message-ID: <874jrntac6.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21183 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1200 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gregory Heytings writes: >>>>> Nobody is saying that there is no bug here. I was only pointing >>>>> out that the bug is not "in Emacs", it is in the fontification >>>>> routines of a specific mode. If you turn fontification off, you >>>>> will see that Emacs 30 behaves much better than Emacs 28. >>>> >>>> And when that mode is part of Emacs, the bug is in Emacs. >>> >>> That remark misses the context and the point. >> >> The context is that you dismissed a bug in nxml because it cannot be >> reproduced in fundamental-mode. >> > > That's not the context, no. Nor did I dismiss a bug, read the first > sentence above: "Nobody is saying that there is no bug here." Nor did > fundamental-mode play any role whatsoever in this discussion. Here is what you said: Nobody is saying that there is no bug here. I was only pointing out that the bug is not "in Emacs", it is in the fontification routines of a specific mode. If you turn fontification off, you will see that Emacs 30 behaves much better than Emacs 28. or, simplified, "Nobody is saying that there is no bug here. There is no bug in Emacs." Now, people will think we will not fix bugs in nxml. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 07:11:49 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 12:11:49 +0000 Received: from localhost ([127.0.0.1]:58079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSGdY-0001so-Jq for submit@debbugs.gnu.org; Wed, 15 Feb 2023 07:11:48 -0500 Received: from heytings.org ([95.142.160.155]:57892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSGdW-0001se-Rs for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 07:11:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676463105; bh=zL4bNT6GoOjzIne3emh5Az/rNJspkbk6vaLaahkRfWA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=kXrwpfSRUtlIZDNRtuw171j2ruUSSjK68zbkouq1JSLt3OmjN4Kx7KHUL9PBKUYgq ZO4iPbLDE3wzokkJwIhh748xxibFyAj4ZrkD040n//B6Q7i19FLf7wws1/LumV/Jan wR9Avb06UMepwc0gEfpM2W9smXXxiORdICOLLPiXpmE1HZ4lkp5SZU6UQEfAjdt11d sCAe4pknXVckAaj4oOS+8bxq7yg61qpP6m+5tm7ABJeKPVLTCM3j8ozYrhhSMkxA2u wm7Q6ylOlBGfA7RvAgOLvO2W9P9H/lVVnzYUaEmmvjf3KmMmdT5Hsv6k2RpybiNyBs YvbAA7aIsCThQ== Date: Wed, 15 Feb 2023 12:11:45 +0000 From: Gregory Heytings To: Po Lu Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <874jrntac6.fsf@yahoo.com> Message-ID: <9e9ed8043fedf8471ab5@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> <9e9ed8043f2db866e3ba@heytings.org> <87cz6btd3q.fsf@yahoo.com> <9e9ed8043f2342b86537@heytings.org> <874jrntac6.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > Here is what you said: > > Nobody is saying that there is no bug here. I was only pointing out that > the bug is not "in Emacs", it is in the fontification routines of a > specific mode. If you turn fontification off, you will see that Emacs 30 > behaves much better than Emacs 28. > > or, simplified, > > "Nobody is saying that there is no bug here. There is no bug in Emacs." > That is your (very) personal interpretation and "simplification". > > Now, people will think we will not fix bugs in nxml. > Was this bug perhaps marked as "not a bug" or "won't fix"? If not, why would anyone think that "we will not fix bugs in nXML"? Now, if you have something to contribute to diagnose or fix this bug, please do. If you don't, I don't see what the point of your posts is. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 07:20:30 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 12:20:30 +0000 Received: from localhost ([127.0.0.1]:58105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSGlx-0002Fg-Pz for submit@debbugs.gnu.org; Wed, 15 Feb 2023 07:20:30 -0500 Received: from mail-ed1-f45.google.com ([209.85.208.45]:44850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSGlv-0002FK-1n for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 07:20:28 -0500 Received: by mail-ed1-f45.google.com with SMTP id v13so21740750eda.11 for <61514@debbugs.gnu.org>; Wed, 15 Feb 2023 04:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=GC7oN6o6sbp56DG6/w4vIsCrMuTUKlHXvPGi7cYnqyI=; b=oVK04gp/JxIDvF7SZftUxImOVtv4cNAcUejeCJeaRsEeRi6aXQkHJxy/BQ0nD/pLIr XIevWkTJKlItJZ90ZDfTVfQodrENnEs0khU/TEEkSBSXuITmGf1NJ8EmMMdb5Aak0/9e 6dDyvRVSGoiSJi2C3pSaz4n6mhk7JvWseAHypCBHnMrrMrkZAO26htXA2uOQwhJz/aRS ssThld4hQb3c0OPRMSiccUSAMoUT1CfkT4UGkWX2qln2CG4QAEID+ny9dsrsEf8DyqzD Qt+DX3+uA3W7/K5u6QhA9SG3QbVfVtx2xNCnjszvT1Ip0PJ0+4vxdxmKbaEA67ctaja6 jhvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GC7oN6o6sbp56DG6/w4vIsCrMuTUKlHXvPGi7cYnqyI=; b=8NFQkiO5e0XMy9pjJhnAGCdUDwfBBDD2g/ArJONtFoL2MLdM+yEssvI709Z9rVd6Eg 0+TIlrOkGS3Wx1fYuZES3te27T6iqpYY6+/OBIHtKlsn8epME2KzCluaB+ljMilEwHEH 8sdtlcJ3oy+OMm3OBUzKweQsljZeSjLAhVH5ACvsfKuSJNpSN98kWAAGv0yzUnZk3cIP 7pLdv6EDguFYpodzffxkRLCFVCSfYlTr/TPPosGv2Tdcv3xJq3pC6h8WamRlizcogy6e 8I7MXNB7nqquMjq91uWtxjyq18h5UP8G2yoG3z2S37gFxAqs3jYcaZh8S2BOV4SzvHX+ bECg== X-Gm-Message-State: AO0yUKXwIQPLnlCE5gQBRnuJdJh+j1DYeVZAmRHMrKO0rvCcwT1AlPPI XA6A1LIGSvxO9ejcz1ZFjpw= X-Google-Smtp-Source: AK7set9Fw0PEO0KVwN7YIMv8gfhdvcQXAob57WYRoDIHKjX5norAsrAv49ZYlgd2k9eCiQ7QhUNKyw== X-Received: by 2002:a05:6402:2b8d:b0:4a3:43c1:8438 with SMTP id fj13-20020a0564022b8d00b004a343c18438mr3164907edb.12.1676463621134; Wed, 15 Feb 2023 04:20:21 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id 15-20020a50874f000000b004acc02d1531sm5112867edv.14.2023.02.15.04.20.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Feb 2023 04:20:20 -0800 (PST) Message-ID: <193237ba-9579-e71b-10ca-e13c2fdad0ae@yandex.ru> Date: Wed, 15 Feb 2023 14:20:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs Content-Language: en-US To: Gregory Heytings , "Mark A. Hershberger" References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> From: Dmitry Gutov In-Reply-To: <9e9ed8043f6ceff84cfc@heytings.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 15/02/2023 10:39, Gregory Heytings wrote: >> The point is that whether it is a bug in emacs "in general", in nXML, >> or in glibc. The point is that there is a regression in how emacs >> behaves when loading this file with long lines. >> > > Nobody is saying that there is no bug here.  I was only pointing out > that the bug is not "in Emacs", it is in the fontification routines of a > specific mode.  If you turn fontification off, you will see that Emacs > 30 behaves much better than Emacs 28. It sounds like the bug lies somewhere in the intersection of nXML and the new long line fontification handling in Emacs 29 (with narrowing, perhaps)? Which part is ultimately "at fault", is a matter of perspective. In practice, I guess it will depend on which of them is easier to fix. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 07:56:43 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 12:56:43 +0000 Received: from localhost ([127.0.0.1]:58153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSHL1-0005kQ-2K for submit@debbugs.gnu.org; Wed, 15 Feb 2023 07:56:43 -0500 Received: from sonic302-48.consmr.mail.ne1.yahoo.com ([66.163.186.174]:37794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSHKv-0005k2-TR for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 07:56:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676465792; bh=PwfniKDPXuHmhkWP7ob1WurfHwhMIML6sQ5WVv5uPO4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=JN/PiJIXMgZ+ikihRo/2CQ/JppGl/lkbxxHjhBCe30+8KI1gDBNJXsTewCjhrfbSsDmtjUNwY5yz1E5MbAKFCk1HXBYAz7tINrIW6RVxa1xzMXAZWNKqsNxNFva318gvDqT0OKCSqYbaFT/SN0j1zQuFpKUEkbqGDQ/dKNy4mnmMm4MfSR2HQBzmBcumN225EoKj158XlnMAedCWNV/r1L9Pgmy/37mOW9Co0wQoOlhCCqC7HOHSP+ulA+6XacwvU+1VuoSkG1y1ujs1apIPDlQjMuHl4Mx/KUNJqI44rbDwMWrsACsSJuIpRKpFOH1xX1JOdGyMh6NGmXqOEBiNQA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676465792; bh=92kIYGe6jGwDKlAXb6v89BVn3+YH4YhdqODCnWf6hNo=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=n1QzVlqUnF8a4EJNkiLosA1cSZM86CuWdfOzNj2VwDA2AHT8dQMPdbpzCXPk9cepMOrDdJ9IVICVsF3aOeqtUrTuy0sLo4+7vSRKP0XBGTsr6Jee0ZOthL0KzEPmsPFa2fv7eDs5YCl7xIVOZEv2l7fANxofJsNHTfHgcvimnfF3j7Q3SI4E/v/HZEDzeQ/BhMyq+hEYR1X8J+VUD6AXUOjnvErrHlbokiLeCmxKzNoRSIicpPCXqXoooKxrmbRgyic89KycydTSvmximvARAl9I+17Vli46PLqm6befqhyZDAeCgyYrwzKb6XKY/0gerBidcEAArFhZ1tQc2SyncA== X-YMail-OSG: 10BppI0VM1nMdbtuGkZtrsGFh5fevKMaLQIuYRU7Z.wey_QAVizpe5ZqT9mC7pO a2e.MyGzaK9WjseNbMN1H.33.PlGzC3zpQvD2b1sppcD_0Yu.z10B_cxpLImXC8G8E.wiJjNjoiJ gHN4ybD9.QDD55_ac.w4YzsN2LOlOCk0td2ii8Volw8uW00SaONvf_GhXpZxomMUcA9BBwddu8EQ 1Hqnw7OjImog.zGaRp4Mz_pw08wmUkVK27c8H7ARCPvril1LxmML6ac1Y3WWa13Tqt_i.JDA_FNO 2XhryOakrAXXaKqttu9I7S4dEKldJDIrX8KJgg8mUocbLPFSR1QJ5vgTl_HimtnOPp6nFYXYnBTl e.nV_Ti.Bcwts_I5gcJHbhoKyVnx0qk6KagGQASG.9cRjo_L0o5pqWK6o6v1htm2TA2Rnu2UDOkr VzV8GAn2MQPKQk.K66wMdcRqS2QeM1tesnpVoDLBTdz5P14pXbaiGBUfEAO_rGc5HRK_liyOgbIc 4rRX5.FVj0qucMhjRWaB14YrOSIhH2zMTJauecHVo8yrXLRirfCl76NBabF86LHuLqOAQEMQW_Xz YHKLDFqXTwKltBsgoJbPAakOSu5.S3FESlKHFJ8VbYCJq7KUj5.q2iM7aG9eRSfUAGEYEZA3ay.N LSK0rKYt_OOCYN9VpRwmkVhFdYUBwceVtqrz_oyUT9OUq.kaZIOkf7vKdz5SREpfXXuY.WJExUnZ 2zezegiiUkzZMPnx6JkCLvBhmRq8ptrmpwwknbEBkWuNA4W9XBVMZ9HOkUOEXPamF5.2y23VqktJ BKOz18tRmxnQuXSgjkewxxZysGHcuIGuz.gF3XS.KEM6kGoAcrz02mwsrjp94WLYxse0JICvwYjJ BXoaOAhmqS.7Bpbkc.GRhlgyauDQ_GIF3GMzNEgys3h9Lh63tL_HfgadPr7dw5g63lq51FGJsHW9 LkJkiWP2FiGNVkl1wnh5VhyosA1LWFNue5oxhS0e0p1jfHZrL5oZ8RdsxSDO4aTB_MpBzdbk3ZNh AfVPnResU8yML6aMNX9SWSJ8nndV.t3WDXdIx9dxWUNU80cTW0ZSNaQTHVAtyPE_DOVXMlRwfIcQ 8k5trynxdoNG7Z8ywVVH522Wgnei07bZIAIYn6NG.GWz8YsfgiNLM3AnFTgHO_PsYE9U3FH9UovL 2Cx0DOoC9ip4hPWIrJ5hn24ZSLJ4Ug_1iaoOXoXszPc443egZzfKZ.OaLH4oJ5ZLYRoy6IEB.wmF pnzyxBtwEERigt_KB1VOPhU6Oe_71mZ3PqA1toZgfN4rmJpeaevFOswF1raONcegmlw34Jgkra1o bv9hW_k0BLg8mDQu42upFL.3F_jXQwaLNtRJMLKQQfGd.vl2yjqHFF4ZVT.SmKZKyxHXHZJBRmZZ lsOzjmCNsHpfydEn5CxZd9fnZs8HEgrrhacn1vP3Ndrx3v7luI7YqOp7Rz7m2ria4q_nhZR7bsk3 WPLmjxnTH9GdLk4wE_uEaW5CyyaXOM7T8lT3N7WmBh4MtX6xEj6InjDauQPSvPMNhfCMB1F8vDVp _WfMl1nc3ygMhTkxKIj48xV5tTTlKmazuE_UAZUZDACGz.S7zhlNSyTMwbA7DKG8GLBClzj8koyZ H1zDqcxFy9kOWf6KmQr99cEiZj3UiQA9l8_ZNSlJ9_Rwn7C5u.LQV.5M7q8d6.j1k7lZ9xJ.mTdF LtRJGgZ2T2H3YrFeBTi9c0eDDp1W5dnF8ImRPIpGErtq_rN1o23TQC_qFqmTtaB6uPw1PPgqw1vU jWm8C.jFlkYYeXP1EPewWY3qtE2rSs8PwWKCpk2jimBZ.1gcGJUndeFg4TwLpyknHZKJJrrE1nl6 iSeSvKiDcXFRKUIr7efPE0TZ__RKejV7OIefhVAggy4h1PfP4Pa0fjRXvJ.AB1YVTdbWUOGRROlZ fI3V5xmPKCVhKXGsa.ooZHV_lgtube7ErBeNH0R_WRR1GjKlqKOBIdfY_4C4VDK2oyz_MeojJ_Yd vc4.vn0OOFxYVqUAl6vGVUDZyspBlSUAzKtNcqOVnjkquvl0Pad8IefmxEEZS8EZOnS.x8GiphTm YyMO_B5HQ6XAp65IxmsJVCqvXj6hIY.R0KmRVfajJU4JqcTpAGbrCNVs26oVo9mpiuzOH6CxzhZT Zhzxv.d6_NJpRtI8UU7tGdRs8tzT8oDCWnzL.1GS_Up0ur21agRwsmQsXcFEEvzG55iYdiXXyHsp xbv3ofhJvCP9X0y7.Rz3DJA6EZlfA5bEmxS16LPjbjX2rmQkHe0DjCA.FEfoyc9tcN.o- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Wed, 15 Feb 2023 12:56:32 +0000 Received: by hermes--production-sg3-9fc5746c8-nc5k6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a9984cc903f015ae8521efc0d7c35823; Wed, 15 Feb 2023 12:54:28 +0000 (UTC) From: Po Lu To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <9e9ed8043fedf8471ab5@heytings.org> (Gregory Heytings's message of "Wed, 15 Feb 2023 12:11:45 +0000") References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> <9e9ed8043f2db866e3ba@heytings.org> <87cz6btd3q.fsf@yahoo.com> <9e9ed8043f2342b86537@heytings.org> <874jrntac6.fsf@yahoo.com> <9e9ed8043fedf8471ab5@heytings.org> Date: Wed, 15 Feb 2023 20:54:12 +0800 Message-ID: <87sff7rswb.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21183 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 650 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gregory Heytings writes: > That is your (very) personal interpretation and "simplification". Evidently, no, judging by Mark's reaction. I quoted, verbatim, you saying that it was not a bug in Emacs. > Was this bug perhaps marked as "not a bug" or "won't fix"? If not, > why would anyone think that "we will not fix bugs in nXML"? Because that's what you said. ``It's a bug in [NXML], not in Emacs''. > Now, if you have something to contribute to diagnose or fix this bug, > please do. If you don't, I don't see what the point of your posts is. I was trying to reassure Mark that we are not going to dismiss this bug. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 08:31:35 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 13:31:35 +0000 Received: from localhost ([127.0.0.1]:58230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSHsk-0000i9-Qh for submit@debbugs.gnu.org; Wed, 15 Feb 2023 08:31:35 -0500 Received: from heytings.org ([95.142.160.155]:57998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSHsj-0000hz-2R for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 08:31:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676467891; bh=daGhJIO+M7qN0LF4q9IPoxDtDa8I9Su86i25vUcje60=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=68k7IO8kd0A7leRov3Zxpe2DKSY7nrybAD+xj6a++WPYf6LYpyLi/EA5fe1HdNlGY FdF8sYgfNV1u1wyJ4AaqlwzDu3jDSTtKJwUu3HEP8KPjxraWdl22KR0MpUU3MyBFB0 O7fWd2Pf/c9ONNCG+zCqUzAop8FGzd1TqCPhWrhrHqR3uBg/kqKUCC36CH9fM7/Yne KS6cMCS35zIRn76wVnogymmFDsfE7YiH/0s+cEH5g1oVOKbykbuu3+JYbDn+5HZu4u 0c35pLSvAfxarH6Gcr6QzSEl16x5euOn0X7ZXUzPb+eYUxcel9TQcUelulgedwItOF M84zrcNmbikhg== Date: Wed, 15 Feb 2023 13:31:31 +0000 From: Gregory Heytings To: Po Lu Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <87sff7rswb.fsf@yahoo.com> Message-ID: <9e9ed8043f6071b97d84@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> <9e9ed8043f2db866e3ba@heytings.org> <87cz6btd3q.fsf@yahoo.com> <9e9ed8043f2342b86537@heytings.org> <874jrntac6.fsf@yahoo.com> <9e9ed8043fedf8471ab5@heytings.org> <87sff7rswb.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Sorry, I won't continue this "discussion", in which you feel as usual free to attribute whatever meaning you want to what others say, with you. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 08:57:16 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 13:57:16 +0000 Received: from localhost ([127.0.0.1]:58285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIHc-0001X3-52 for submit@debbugs.gnu.org; Wed, 15 Feb 2023 08:57:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIHZ-0001Wm-Gg for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 08:57:14 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSIHT-0002h5-Vi; Wed, 15 Feb 2023 08:57:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=quKwRz3qEi5sqNNI/Uu+YbMBi527S0fZlNqHjh5Ul7U=; b=f05sQiZM6HF9 //0K+oObxSfn4R0jgOjugJibR8+fwZtS66fMDO3XL7UmeY4di5m7U95uZy3CWfoqDofIm0KpLH6Y5 9xtMkuyGWob/+5V7vu6M1mIXApgMLqBuyPF3AXxytIMtPW1p2pdwRc9oqXhHG+HBA91DLpusNZTmZ YEg+GiaA4YWdg2ItWJ+5XcshYuzPo46zlxfjRNDBky2MAVB2PRO0ZIzWOwckNl26F+6BbrG+HbEWq 7pmp2QSiL8quGf1yQoPNClL+CK83nlJHk009DLlcGt8SKwh7eXkxhp/SjZnNUCDyxKqQMH0D9col3 13/Jy/pQuiYo3w9sxyKsaQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSIHT-0004if-9A; Wed, 15 Feb 2023 08:57:07 -0500 Date: Wed, 15 Feb 2023 15:56:49 +0200 Message-Id: <83pmabav6m.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <874jrntac6.fsf@yahoo.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <87h6vntef0.fsf@yahoo.com> <9e9ed8043f2db866e3ba@heytings.org> <87cz6btd3q.fsf@yahoo.com> <9e9ed8043f2342b86537@heytings.org> <874jrntac6.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: gregory@heytings.org, 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org > Date: Wed, 15 Feb 2023 19:52:09 +0800 > From: Po Lu via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Now, people will think we will not fix bugs in nxml. Please cool down. No one said this is not a bug we'd like to fix. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 08:58:40 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 13:58:40 +0000 Received: from localhost ([127.0.0.1]:58295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIIy-0001Zu-44 for submit@debbugs.gnu.org; Wed, 15 Feb 2023 08:58:40 -0500 Received: from heytings.org ([95.142.160.155]:58078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIIw-0001Zm-Ko for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 08:58:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676469517; bh=lS3aDpIz7peYBrA5JvWbVmV6duBgoReRSmZn6QKYVzQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=gE8WBjGxPC/PsbRkIcMgcdrRDiTu8I9R6yKOXLwnQb2sDSK+Cb4jjRIU3LYwunfEb vWQSIoOkgZm6+KwJG/CQo7lW7/+sjFUncj6XR1ayx4WycHsdBQeqx53V46G88Uqk42 hYWnCq5I46/zy5jrF7vFneMn/DruFb7NSdsxKNWuFluZq9usINKlW1hQll10cW9iqt UdmiO+zFOYIwnYGAMpd76AaufPScUu1ou/Du9TkgcfSVC1mwawDewu3jw1oLk8/mYj dIfRTCJMl0ttJf2k86os1MtDvwHG1ZvsQjJ4PXl8GJ/keTVWBYToV3gDQT2SOaGETq hL/3t7BYvFzFQ== Date: Wed, 15 Feb 2023 13:58:37 +0000 From: Gregory Heytings To: Dmitry Gutov Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <193237ba-9579-e71b-10ca-e13c2fdad0ae@yandex.ru> Message-ID: <9e9ed8043fd6295f8b5b@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <193237ba-9579-e71b-10ca-e13c2fdad0ae@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > It sounds like the bug lies somewhere in the intersection of nXML and > the new long line fontification handling in Emacs 29 (with narrowing, > perhaps)? > Yes, it's an example in which the cure of narrowing around fontification-functions could be considered worse than the disease. In this particular case however, the fontification routines already failed to do their job in Emacs 28 (and 24, 25, 26 and 27): after opening this file, errors are displayed in the echo area, and the buffer remains unfontified. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 09:17:49 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 14:17:49 +0000 Received: from localhost ([127.0.0.1]:58344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIbV-0004Vy-Eq for submit@debbugs.gnu.org; Wed, 15 Feb 2023 09:17:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIbT-0004Vl-Lf for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 09:17:48 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSIbO-0007sr-7Q; Wed, 15 Feb 2023 09:17:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SqWH3sJd0mRAokunpt92Dl9SOp78K9jfvS2KwPl0Kr4=; b=JhSGBgao17K3 vnAa3AmH+7fpxZFYMbsUj9qC5JOpkxw/vwI8ui+c6nacb+3CjJONwfZav3NAUJ/HXMHNBblMhrSTv 6kvvoN7uFzkgAwlewf7MPcnz0HtXiwCxMKlUloIc2r/6wI4X+tpt3zY61xq0rXms6bDiScqSCXmDh o88Ym6PNuKDPniqa/WPiPFWcJGPZzIh4fkpeyFh3O646oo647XQHvK2rwHSWeQvTBBWES34srjqan TySJ/ePZcqMnT+t79gawx0KDy7X6YTYqDMR3+Q48pODz3dWNhNs5tG56OlY0srkdsAaiS9De2L+Ds GaIN8bLcG+iiZXsSEb1jxg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pSIbN-0000Vf-Nj; Wed, 15 Feb 2023 09:17:42 -0500 Date: Wed, 15 Feb 2023 16:17:24 +0200 Message-Id: <83edqrau8b.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <9e9ed8043fd6295f8b5b@heytings.org> (message from Gregory Heytings on Wed, 15 Feb 2023 13:58:37 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <193237ba-9579-e71b-10ca-e13c2fdad0ae@yandex.ru> <9e9ed8043fd6295f8b5b@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org > Date: Wed, 15 Feb 2023 13:58:37 +0000 > From: Gregory Heytings > > > > > > It sounds like the bug lies somewhere in the intersection of nXML and > > the new long line fontification handling in Emacs 29 (with narrowing, > > perhaps)? > > Yes, it's an example in which the cure of narrowing around > fontification-functions could be considered worse than the disease. In > this particular case however, the fontification routines already failed to > do their job in Emacs 28 (and 24, 25, 26 and 27): after opening this file, > errors are displayed in the echo area, and the buffer remains unfontified. If fontification-functions failed regardless of the restriction, then perhaps fixing them so that they don't fail will also solve the greater problem? Btw, how does the narrowing make the matters worse, exactly? what is the mechanism of worsening the situation in this case? From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 15 09:35:02 2023 Received: (at 61514) by debbugs.gnu.org; 15 Feb 2023 14:35:03 +0000 Received: from localhost ([127.0.0.1]:58382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIsA-0004yn-6Z for submit@debbugs.gnu.org; Wed, 15 Feb 2023 09:35:02 -0500 Received: from heytings.org ([95.142.160.155]:58186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSIs7-0004yL-81 for 61514@debbugs.gnu.org; Wed, 15 Feb 2023 09:35:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676471697; bh=IHkL7o738eo4iLy8+scWCs6wX8DxiIELzNxK8wrbKwE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=PSVqudFItthesEFOoY/AJvgW7vq1o1RJVkbELD/KVhj1oksxGR32hqRyBlvAYH92i jhSBXZbQhTEU4gq+Mfe/5kjVMqqdOv172ESO0CsdVrrfM9JWjTXhej+i99p7pbtEQM hLArPYdMHi737av+VprSzLVp/fVCMcnobqbZ1uObpaBXqP8d6RCl20jJBw0GjYzSuR euUo6SciRr5hQz/0wyvurUeW62zA+ve786aDQXIo7JoS+NtX7XTVAJukUXCYTuys4R CfCHoczkDO41lQQ8STJuRiwznbAn2JBRggUSS/zkFDSdONyaHtxrj7K4rxCN2ZBwYN XUW11IiHmE5Sw== Date: Wed, 15 Feb 2023 14:34:57 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83edqrau8b.fsf@gnu.org> Message-ID: <9e9ed8043f204a6987a5@heytings.org> References: <87lel0c65v.fsf@everybody.org> <0f053182b05e84d6251e@heytings.org> <6ec29aa7157c40ce76e9e0cf1a6351871e16ecd7.camel@everybody.org> <9e9ed8043f6ceff84cfc@heytings.org> <193237ba-9579-e71b-10ca-e13c2fdad0ae@yandex.ru> <9e9ed8043fd6295f8b5b@heytings.org> <83edqrau8b.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, dgutov@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> It sounds like the bug lies somewhere in the intersection of nXML and >>> the new long line fontification handling in Emacs 29 (with narrowing, >>> perhaps)? >> >> Yes, it's an example in which the cure of narrowing around >> fontification-functions could be considered worse than the disease. >> In this particular case however, the fontification routines already >> failed to do their job in Emacs 28 (and 24, 25, 26 and 27): after >> opening this file, errors are displayed in the echo area, and the >> buffer remains unfontified. > > If fontification-functions failed regardless of the restriction, then > perhaps fixing them so that they don't fail will also solve the greater > problem? > That's what I hope, indeed. > > Btw, how does the narrowing make the matters worse, exactly? what is the > mechanism of worsening the situation in this case? > I guess (but did not yet have time to investigate the issue in more detail) that it causes an infinite loop somewhere. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 11:23:05 2023 Received: (at 61514) by debbugs.gnu.org; 18 Feb 2023 16:23:05 +0000 Received: from localhost ([127.0.0.1]:44772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTPzM-0002yt-UG for submit@debbugs.gnu.org; Sat, 18 Feb 2023 11:23:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTPzL-0002yD-6K for 61514@debbugs.gnu.org; Sat, 18 Feb 2023 11:23:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTPzF-0002Xn-LE; Sat, 18 Feb 2023 11:22:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bu736oO601COnKWJ8R/06T9lnV7bUB0dik8fK3SKsFU=; b=DWzNhndlLM0z o9Jqr0Nl2wibU0J+WTQzAMipQkZndKEBF2+fwl2DUlq4b8lYwHX6k90b7pJLlrdxswxLuBGOFduHN 1js2tj4ZQhlffTw+wAX/M58MNC3flVIQE5uKYnrauaXcC42QYrTEZ3BHYM9MyYbzWeWvblX3iv6pd MCExe5SG/806RYHz0qRiFNuTSuQDbz/kTtyUBXXhVpM/ZJySRPPtIK1lyxNSHmnCzsG8fTt26N73l F2rHG6aeKjyAMoekxG503Smf8DYZKb4hFir+xRAoUqhpHmFl40X/Agww8xdC5yf7B+5HoyysLL5xY 8iU8lViEgSGAP+kvi4CHeg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTPzD-0004T4-V7; Sat, 18 Feb 2023 11:22:57 -0500 Date: Sat, 18 Feb 2023 18:22:58 +0200 Message-Id: <838rgvymcd.fsf@gnu.org> From: Eli Zaretskii To: "Mark A. Hershberger" In-Reply-To: <87lel0c65v.fsf@everybody.org> (bug-gnu-emacs@gnu.org) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 14 Feb 2023 16:02:04 -0500 > From: "Mark A. Hershberger" via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > There seems to be a regression between 28 and 30 with how emacs handles > long lines. No, there's no regression with long lines. There's an existing bug in our regexp routines and/or nxml. See below. > Bottom line: Emacs 30 is handling files with long lines worse than Emacs > 28. This conclusion is incorrect, or at least inaccurate. Emacs 28.2 has the same problem as Emacs 30. Take that a.xml file, truncate it after 250000 characters, then visit it with Emacs 28.2 -- you will see that Emacs 28.2 freezes exactly like Emacs 30 does. The problem is in the combination of nxml-mode and some subtle bug/misfeature in our regexp routines. Specifically, when we overflow the fail stack, we fail to recover in this case, and seem to infloop inside re_match_2_internal, or maybe recover very inefficiently (I waited for almost 1 hour before giving up). The call which causes the loop is in xmltok.el, in the indicated line: (defun xmltok-scan-attributes () (let ((recovering nil) (atts-needing-normalization nil)) (while (cond ((or (looking-at (xmltok-attribute regexp)) ;; use non-greedy group (when (looking-at (concat "[^<>\n]+?" <<<<<<<<<<<<<<<<< (xmltok-attribute regexp))) (unless recovering (xmltok-add-error "Malformed attribute" (point) (save-excursion (goto-char (xmltok-attribute start name)) (skip-chars-backward "\r\n\t ") (point)))) t)) The regexp that causes this is as follows: "[^<>\n]+?\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 12:06:41 2023 Received: (at 61514) by debbugs.gnu.org; 18 Feb 2023 17:06:41 +0000 Received: from localhost ([127.0.0.1]:44812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTQfY-00047P-Ui for submit@debbugs.gnu.org; Sat, 18 Feb 2023 12:06:41 -0500 Received: from spam1.m5hosting.com ([206.71.179.219]:60778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTQfX-00047H-4K for 61514@debbugs.gnu.org; Sat, 18 Feb 2023 12:06:39 -0500 Received: from mail.nichework.com ([108.161.151.158]) by spam1.m5hosting.com with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pTQfK-0003Av-Pe; Sat, 18 Feb 2023 09:06:37 -0800 Received: from mail.nichework.com (localhost [127.0.0.1]) by mail.nichework.com (Postfix) with ESMTPS id 7DB764E019F; Sat, 18 Feb 2023 09:06:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nichework.com (Postfix) with ESMTP id 57B734E02BE; Sat, 18 Feb 2023 09:06:25 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.nichework.com 57B734E02BE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nichework.com; s=897144A4-59D1-11EA-885D-1509A2A44C35; t=1676739985; bh=LioYASizkBxSB+dvyroQ7Emoe6uPdogpnEEa9PsMzbQ=; h=Date:From:To:Message-ID:MIME-Version; b=kizUFQ1BnZpI7oftuab/co3pZVkLY9+lXsjfHiVlJ/05VcbVpkv1z6T2/vZSY5zAN ca7pDNX568ogGcHJXyN1E8t1QKKv2YmYGITeQvd3cTYxwXaEf4IkqUVcWx1AfL5nrm vOo10FkiHbv8re0pDo3nnbbdHkjVAsfXdpolya7sTa0UVclmY7ujHf23h5EHB3435N wgVx00sNDKhJHL4onfLegBxGClDyaVk9y4Yh/YHTeLq/Fh9QnxnIqg7+YHn7lqTUpk JdCpYjGb7dHr+YhXlV/pBTLwLP0IU5gsT5YFwTjq02Yh5v3Jjmgj35ZsKt/xCS67CJ NmuHwcg5V3riA== Received: from mail.nichework.com ([127.0.0.1]) by localhost (mail.nichework.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id x5Og-Si32Xw0; Sat, 18 Feb 2023 09:06:25 -0800 (PST) Received: from mail.nichework.com (mail.nichework.com [108.161.151.158]) by mail.nichework.com (Postfix) with ESMTP id 43A314E019F; Sat, 18 Feb 2023 09:06:25 -0800 (PST) Date: Sat, 18 Feb 2023 09:06:25 -0800 (PST) From: "Mark A. Hershberger" To: Eli Zaretskii Message-ID: <678324821.29732.1676739985238.JavaMail.zimbra@nichework.com> In-Reply-To: <838rgvymcd.fsf@gnu.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [108.161.151.158] X-Mailer: Zimbra 8.8.15_GA_4484 (ZimbraWebClient - FF112 (Linux)/8.8.15_GA_4481) Thread-Topic: bug#61514: 30.0.50; sadistically long xml line hangs emacs Thread-Index: VNljmExs1IMqrFaM0Bt/3QmCFlmSzw== X-Originating-IP: 108.161.151.158 X-SpamExperts-Domain: out.m5hosting.com X-SpamExperts-Username: 108.161.151.158 Authentication-Results: m5hosting.com; auth=pass smtp.auth=108.161.151.158@out.m5hosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+6jlkVGJA3t0QPpwSQZQrHPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zoC4Sd6MuPGeS+nH6FJ1zAeeTGE6/jLakLVHLNXqEJIjBn ZTqcVNU3v+WQaLFrAJsBcORxfCojcTOpEjtvWHp2NEVPu7IVsZf9DCjkyo3pRjg9YkzbMy6DOYhG 3MUcvho42E9/62Xj4gVnOU7mzP18zi/cyawvf/Ja1bTLc5OHrOs/uSyOilsPhBVg7F5S7c4JG3s1 28kePw2MKKOfQXfEmumFMH1EwkjftN4HOsZfSbDY27xZiOmTUqT1Bu490izs/sb16ESDOWr/ATs5 NT2bPEg+PVRTiaxPY52n0Pp/8/afKMC1CfM9pITDVvMyZT+1eZ2E8T8HmMZ1rYkweA8e/knZBuyF omiBk8BiJk4g45D1NLwT/8kBzH04VXGGLy1qy4TFaO7Oawv4tcQOp8LxvCrJPmnnTHzVkpybMK7Z TRfChJU65j2oGK7LqJOPIfjAJupClnw55DHDhrZT1NFUi+FIlxudf8dCov9f2s0IkJzqIRIm8qbU 1XyCSv5a7xJxUNeKc5XK4ikhND3PczcMnexhoHDZcJtp297sqOPN5G6mc0eiAtYVsFe2wtUPcX+R +vGayFvy1BP8bR8OlxSjcy9sn7rYlcSS1p7CLKzXH4BxxH7jKzQrASM/rVArlI8assIBZov1Q6bX UqzLTHJQCIH5WfJzueDOU7rhKuGVkmU0WctuTj5uNf/tRREwvXaBv8JXhuXW6eD5M2OhJWtyfLEn L2yUDqb1vjnTsUJde6ounHQ/VQOPO7knDKvXcYA8CVsONrMJuGzuoGnKTKcyUYKXzwo3lIi1Fy93 m+W8vUw/qpmJ2/7FRV6fvpfVMJQmo9xeN/Eyl7NH9mgZS5rWVIWY2TUFwp8EGGl7wMsOqaEsmgNU 80KTDQcWwe0S4mDROeCeUSphZgz2ILu7wnFUjsCIkdyfSH4fVMCH017JwYUGPfP82tKuBqC60MYp II9GDQu8fl/x+jLP1pq3IxuKMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@spam1.m5hosting.com X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli writes: > The problem is in the combination of nxml-mode and some subtle > bug/misfeature in our regexp routines. Thank you for your work in tracking this down. That regex looks pretty awful. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 12:58:40 2023 Received: (at 61514) by debbugs.gnu.org; 18 Feb 2023 17:58:40 +0000 Received: from localhost ([127.0.0.1]:44912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTRTr-0005Vl-PH for submit@debbugs.gnu.org; Sat, 18 Feb 2023 12:58:40 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTRTp-0005VW-5B for 61514@debbugs.gnu.org; Sat, 18 Feb 2023 12:58:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTRTj-00031N-Qp; Sat, 18 Feb 2023 12:58:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ON+3ED6wcER09GklOQ90yXyUStidZxWOWtihAipwSKs=; b=DXXFDDdhwbkd oNI2G8tNLrbqQrso4bDhIXIBaGMgx8UtiG4ae9s2Trcng7/fGJEQP+vqptzXzZGnvy4X+72MknV/8 cI5/Qy+Y9RaLnu0r/aiKV0TjR9i2ko6Gu7kAOAqiM4LSPs2MAOoeyNgMhRRpkQgRAW1tpy6ilV9WS i8M07XUUFAco/xj+XvCX3gWiWx2eZfYiQDMmfGuyg5CzEjamOg1R+E/9qBvjkn6wSpKxOeYVQflLM QIhfnuY/bzmSgzGedtFaTS4mTAqOYXBu6a3Fb6soDXDEQNbXBaRPhixzB2Zji/2tdhvtPOn2csQcc 58i6wQd8rfZxtyWVKgB+0g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTRTj-0002oi-AM; Sat, 18 Feb 2023 12:58:31 -0500 Date: Sat, 18 Feb 2023 19:58:35 +0200 Message-Id: <83wn4eyhx0.fsf@gnu.org> From: Eli Zaretskii To: "Mark A. Hershberger" In-Reply-To: <678324821.29732.1676739985238.JavaMail.zimbra@nichework.com> (mah@nichework.com) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <678324821.29732.1676739985238.JavaMail.zimbra@nichework.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 18 Feb 2023 09:06:25 -0800 (PST) > From: "Mark A. Hershberger" > Cc: 61514@debbugs.gnu.org > > Eli writes: > > The problem is in the combination of nxml-mode and some subtle > > bug/misfeature in our regexp routines. > > Thank you for your work in tracking this down. > > That regex looks pretty awful. Yep. And coupled with quadratic (or worse?) behavior of our backtracking regexp engine, it's a killer. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 18:06:18 2023 Received: (at 61514) by debbugs.gnu.org; 18 Feb 2023 23:06:18 +0000 Received: from localhost ([127.0.0.1]:45145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTWHa-0005gm-6j for submit@debbugs.gnu.org; Sat, 18 Feb 2023 18:06:18 -0500 Received: from heytings.org ([95.142.160.155]:34662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTWHZ-0005ge-46 for 61514@debbugs.gnu.org; Sat, 18 Feb 2023 18:06:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676761573; bh=jPecWNFx6+U1KBf8HvK5zEsTKhA5tujfJAshX18BnUw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=nX1lkgXL8jOFepgjP2dpBmMfjN8VbT8CuiSjpuZukPpl5vV8pyhfGYvREt6y4qGGr 3M2T14CcpCkhqMNM905ylh/s3o1IUskR1SGnJIwrVb0LlQ+CdYC/kY/0HE6oWwOgmZ TC8OO/Xnz7eBkdBbkfEQq4qJDs2L+LXZsZKQnjKPO0ozsHLJH1WuC1ESH5dj8Zl7NI VEBBPiJLhTcGZHb8v7nA/5ExoKst6zNEvofqVqB3O5oqQO5YB8jXq+3FVCTykjAs+v AYc/5CyAKKcbQZBooNaUh1zGPD4c4vgIaLEPh4SkLNIBS16gc8QBRhG1QnGk3699dm DuZ0SWBu2OfPw== Date: Sat, 18 Feb 2023 23:06:10 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <838rgvymcd.fsf@gnu.org> Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Interestingly, the following simple patch fixes both the original and the truncated cases: diff --git a/src/regex-emacs.c b/src/regex-emacs.c index 2dca0d16ad9..eb943df46f0 100644 --- a/src/regex-emacs.c +++ b/src/regex-emacs.c @@ -877,7 +877,7 @@ #define INIT_FAILURE_ALLOC 20 whose default stack limit is 2mb. In order for a larger value to work reliably, you have to try to make it accord with the process stack limit. */ -ptrdiff_t emacs_re_max_failures = 40000; +ptrdiff_t emacs_re_max_failures = 37499; union fail_stack_elt { I obtained the magical 37499 value by bisecting. Both cases fail with 37500 (or higher), and work as expected (i.e. they fail with "Stack overflow in regexp matcher") with 37499. I don't know why exactly, but I note that: 37499 * 8 = 299992 and 37500 * 8 = 300000 (where 8 is sizeof (fail_stack_elt_t)) 37499 * 20 * 8 = 5999840 and 37500 * 20 * 8 = 6000000 (where 20 is TYPICAL_FAILURE_SIZE) so it seems that there is a kind of limit at exactly 6000000 bytes? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 18 19:46:11 2023 Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 00:46:11 +0000 Received: from localhost ([127.0.0.1]:45232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTXqE-0008IR-U5 for submit@debbugs.gnu.org; Sat, 18 Feb 2023 19:46:11 -0500 Received: from heytings.org ([95.142.160.155]:34780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTXqB-0008IH-7y for 61514@debbugs.gnu.org; Sat, 18 Feb 2023 19:46:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676767565; bh=Qe7L+sJrESIHNJwp9+MYMy2R5yqcILEowSmTsa29o/4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=talObXeBy+yQWfUf1oKQme0KAPgLxzzx257XAdW52JFIygz5A3PTpqsj36FSfhUg2 j1XRakTlEEy3HD7UADk2jOoVgnREOMN/kYDEoIKqgjpO3SI8I8x1msOJqidDTWcYjN JxckU+QJMWpwP6P8uUGmu4fcCmQ2eklb1z8joYSJ1RVgv/gQj2lLazv+40Os/rqWKu Hy87bTS0nZR5qUUdWnj/9nnIW/dtGwyGos9EwihRJ0FbBon5hr2NaiyppV/0BVJKBz PPtwnNR5MThPA5pX9+l/3ociYjR6N6FaTtv+IvkR0mxh0yQ860AmKQJi6Ui7lwoNoD x6Rp1EwzFyrxQ== Date: Sun, 19 Feb 2023 00:46:05 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: <886c06e50e9cfacb7954@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > Interestingly, the following simple patch fixes both the original and > the truncated cases: > > diff --git a/src/regex-emacs.c b/src/regex-emacs.c > index 2dca0d16ad9..eb943df46f0 100644 > --- a/src/regex-emacs.c > +++ b/src/regex-emacs.c > @@ -877,7 +877,7 @@ #define INIT_FAILURE_ALLOC 20 > whose default stack limit is 2mb. In order for a larger > value to work reliably, you have to try to make it accord > with the process stack limit. */ > -ptrdiff_t emacs_re_max_failures = 40000; > +ptrdiff_t emacs_re_max_failures = 37499; > > union fail_stack_elt > { > After some further investigation, that's probably not TRT to do here. With a file truncated to 100000 characters, the same bug happens with emacs_re_max_failures >= 15000, and disappears with emacs_re_max_failures <= 14999. Hmmm... From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 01:42:26 2023 Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 06:42:26 +0000 Received: from localhost ([127.0.0.1]:45510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTdP0-0000yl-EB for submit@debbugs.gnu.org; Sun, 19 Feb 2023 01:42:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTdOy-0000yV-8t for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 01:42:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTdOs-0007N9-NG; Sun, 19 Feb 2023 01:42:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CBRGYT7VzLJCy6YrsPAabo1XCE2E0g0BMoQm2y7Ffuk=; b=QokBOD70Bv43 wpyD2ZyyebhHwMRwdLWHUKt3MfIz18bFbsCPoluQzb1cbwkdS+7rOV8dT01wo9L204lb1yrMcGfK0 J23Z3UpWKRZo3xQDFFpHMI93ZHPdvnv2Vqfa1GfEsgdxj/v5YEEHlI0kEFEnFALYWRQkdQavBQwEo X7iJaXdO4SYUn4U01SDrU3OBnG+K2JXFoCE27p1VaTsu0C9dqU/FjJYEb7uFaIKLyYXFRjD0bx4hr qeg9+q48bGCJvFsfAP9NizVC4OtE8i60Z/zbEghQusLgasUKTJh+ef4qPNpw+EcIixA65QXkopvrq FRBIuXxAl2yooXcBFEKTuA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTdOr-0007wQ-Bg; Sun, 19 Feb 2023 01:42:18 -0500 Date: Sun, 19 Feb 2023 08:42:22 +0200 Message-Id: <83h6vixik1.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings , Stefan Monnier In-Reply-To: <886c06e50e9cfacb7954@heytings.org> (message from Gregory Heytings on Sun, 19 Feb 2023 00:46:05 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 19 Feb 2023 00:46:05 +0000 > From: Gregory Heytings > cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org > > > Interestingly, the following simple patch fixes both the original and > > the truncated cases: > > > > diff --git a/src/regex-emacs.c b/src/regex-emacs.c > > index 2dca0d16ad9..eb943df46f0 100644 > > --- a/src/regex-emacs.c > > +++ b/src/regex-emacs.c > > @@ -877,7 +877,7 @@ #define INIT_FAILURE_ALLOC 20 > > whose default stack limit is 2mb. In order for a larger > > value to work reliably, you have to try to make it accord > > with the process stack limit. */ > > -ptrdiff_t emacs_re_max_failures = 40000; > > +ptrdiff_t emacs_re_max_failures = 37499; > > > > union fail_stack_elt > > { > > > > After some further investigation, that's probably not TRT to do here. > With a file truncated to 100000 characters, the same bug happens with > emacs_re_max_failures >= 15000, and disappears with emacs_re_max_failures > <= 14999. Hmmm... I'm not surprised. There's something weird going on there. Do you understand the logic in this snippet near the end of re_match_2_internal: /* We goto here if a matching operation fails. */ fail: maybe_quit (); if (!FAIL_STACK_EMPTY ()) { [...] } else break; /* Matching at this starting point really fails. */ } /* for (;;) */ if (best_regs_set) goto restore_best_regs; unbind_to (count, Qnil); SAFE_FREE (); if (max_redisplay_ticks > 0 && nchars > 0) update_redisplay_ticks (nchars / 50 + 1, NULL); return -1; /* Failure to match. */ What is the mechanism to empty the failure stack, which eventually causes us to report a failure? What I see is that the stack is either not being emptied, or being emptied very slowly. Do the "magic" numbers you came up with explain that? Maybe we should devise some mechanism whereby re_match_2_internal forcibly returns a failure after too much bactracking (if that is what happens here), when called from redisplay? Stefan, any ideas? From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 18:12:19 2023 Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 23:12:19 +0000 Received: from localhost ([127.0.0.1]:49929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTsqx-000283-GV for submit@debbugs.gnu.org; Sun, 19 Feb 2023 18:12:19 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45319) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTsqv-00027k-1b for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 18:12:17 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3164E100099; Sun, 19 Feb 2023 18:12:11 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 86626100048; Sun, 19 Feb 2023 18:12:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676848329; bh=L7UULHxRAwNSP6C4hmuGpOCg86USE6OlAKp9lFpQs68=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fPXRaYFTWsM5SKZEjuXV3WMMdOWFxV7bi8m9tk86ltMntGaz/OEsJzJlw7CUovlOh 7jKm9QEjxUxz5xL2ZSLK21up4cuUpJ1mQD0NIePon/NSL8DfiK1HcqJDXV1bVuNSkC UQPzfn6CGfGqCRRO1uk0cxa8miaD7xvSzC5Z1clCM2rtIps0zA2qJgvr6vyStIS9gG /44m8nRlAZemiHj5qe+/HMd90obKEAaLhYcb/vCghR8sV4FYU8RDoeMa6Po8kXer+T XWgtsgQbqdgkkF5sAqWCcvU+txN9pL0ih8/lEuvNDW2Wv/C/xyc9PUDPRt6ea8LDS3 SdPB4Wgh+bnyQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3040B1231B4; Sun, 19 Feb 2023 18:12:09 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83h6vixik1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 19 Feb 2023 08:42:22 +0200") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> Date: Sun, 19 Feb 2023 18:12:05 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.087 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Gregory Heytings , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I'm not surprised. There's something weird going on there. Do you > understand the logic in this snippet near the end of > re_match_2_internal: I should understand it, because I think I wrote (or at least significantly changed) this part (20 years ago, maybe?). > /* We goto here if a matching operation fails. */ > fail: > maybe_quit (); > if (!FAIL_STACK_EMPTY ()) > { > [...] > } > else > break; /* Matching at this starting point really fails. */ > } /* for (;;) */ > > if (best_regs_set) > goto restore_best_regs; > > unbind_to (count, Qnil); > SAFE_FREE (); > > if (max_redisplay_ticks > 0 && nchars > 0) > update_redisplay_ticks (nchars / 50 + 1, NULL); > > return -1; /* Failure to match. */ > > What is the mechanism to empty the failure stack, which eventually > causes us to report a failure? It's `POP_FAILURE_POINT` done soon after testing `FAIL_STACK_EMPTY`. > Maybe we should devise some mechanism whereby re_match_2_internal > forcibly returns a failure after too much bactracking (if that is what > happens here), when called from redisplay? > > Stefan, any ideas? I don't understand the problem well enough yet, sorry. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 18:39:05 2023 Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 23:39:05 +0000 Received: from localhost ([127.0.0.1]:49945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtGq-0002pE-MY for submit@debbugs.gnu.org; Sun, 19 Feb 2023 18:39:04 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtGn-0002oa-MI for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 18:39:02 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0882F100099; Sun, 19 Feb 2023 18:38:55 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 962A4100048; Sun, 19 Feb 2023 18:38:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676849933; bh=lOiXsXp9AKWdgxddbmOSCia/qIA5x76wAHhWg0S4X2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Z4nvZ8iBh4gu8dd9uW/gO6pF5aGFIe66Q8VrpjULIebUNLCes3HOc/ZjqMU/3Iw2H KemvGGmw0VmkCJj/ES9kWRPaaoUfxGiD06SPSWVl3el/UkuCxY5bG/32dHfEpFHLHv Do8F/SeYt6kmsTtixYuNoxkcrTmT0y25MJ5Wpakg8whMO9L0RyAJCrSa5o5l0pL9VQ AxybPyThhLTIl3RFNq29k8gZi0K8T+bgO0XHKfANp5LQOROdce9RmjVtBo7GZyjFcv GoU1fWpC5CXlOs3afXU6f06wbbj1rXeDmzKwHWHWC5SZYCLkXXLJqeXL6jHahbqdf/ mPStJWSFL6hWA== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4620B123173; Sun, 19 Feb 2023 18:38:53 -0500 (EST) From: Stefan Monnier To: "Mark A. Hershberger" Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <87lel0c65v.fsf@everybody.org> (Mark A. Hershberger's message of "Tue, 14 Feb 2023 16:02:04 -0500") Message-ID: References: <87lel0c65v.fsf@everybody.org> Date: Sun, 19 Feb 2023 18:38:52 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.083 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Opening the file (a.xml) produced by the script above from a dired > buffer in Emacs 30.0.50 shows the following in the message window: > > RNG NXML error: (error "Stack overflow in regexp matcher") That's "good": much better than a freeze. It points to the use of a regexp pattern somewhere which doesn't fall into the small subset which our regexp engine handles efficiently, in which case we get typically one stack element pushed per character, so if the text is long enough we inevitably bump into the limit of our regexp-stack depth. We should look at the regex and try to rewrite it in a way that fits better within the limits of our regexp matcher. > After this, Emacs appears to hang and nothing else is displayed. That's a second and separate bug (tho probably triggered by the first). These tend to be nastier to diagnose. It may also come from a poor regexp (except one where the problem is not just the backtracking depth but the resulting algorithmic complexity which can be up to exponential :-( ), but not necessarily. > Bottom line: Emacs 30 is handling files with long lines worse than Emacs 28. :-) As you may have seen by now, this just triggers defensive reactions. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 18:48:53 2023 Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 23:48:53 +0000 Received: from localhost ([127.0.0.1]:49960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtQL-00038S-Ef for submit@debbugs.gnu.org; Sun, 19 Feb 2023 18:48:53 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61895) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtQJ-00038F-QT for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 18:48:52 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6DC5980800; Sun, 19 Feb 2023 18:48:46 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E20DB8051E; Sun, 19 Feb 2023 18:48:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676850524; bh=joRzd6NyieDP589GlzbBCM2zJ83h7t3/hFuUX13UMws=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iE0iPDjracV7ANd46SBEg+Thxd65zIZI29ooceq02arOaO3JrQj518AOTiw+5qtXA KOgjHHhnLtF4V7sPII46ePhl+2QNZCM8Wwt2wonWbXrTe4QUmphgmA/wMN+FkL4eC4 BKIzftxXboyLQkvmGFQu4/u8/WMK0hpYHq53/iX/eleuU6Sv69jnZBFNjiL5HzwzHi 8OWKS5OoOj2o9FfcEtnkZSOmcdhsO5BTP4GY/2Cp3Z2YkxhurHiuEqrgzCgfwWwZa8 X2rGkksp9TcSbi2Zs0dFspad69RphxZXaMKA2yUDBLczjGweZ7WwkDw4dnrHJCzfty JLbaEcALXnlfQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 927BC123217; Sun, 19 Feb 2023 18:48:44 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <838rgvymcd.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 18 Feb 2023 18:22:58 +0200") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> Date: Sun, 19 Feb 2023 18:48:43 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.130 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > The problem is in the combination of nxml-mode and some subtle > bug/misfeature in our regexp routines. Specifically, when we overflow > the fail stack, we fail to recover in this case, and seem to infloop > inside re_match_2_internal, or maybe recover very inefficiently (I > waited for almost 1 hour before giving up). The call which causes the > loop is in xmltok.el, in the indicated line: > > (defun xmltok-scan-attributes () > (let ((recovering nil) > (atts-needing-normalization nil)) > (while (cond ((or (looking-at (xmltok-attribute regexp)) > ;; use non-greedy group > (when (looking-at (concat "[^<>\n]+?" <<<<<<<<<<<<<<<<< > (xmltok-attribute regexp))) > (unless recovering > (xmltok-add-error "Malformed attribute" > (point) > (save-excursion > (goto-char (xmltok-attribute start > name)) > (skip-chars-backward "\r\n\t ") > (point)))) > t)) > > The regexp that causes this is as follows: > > "[^<>\n]+?\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" IIUC the above describes the code where we're stuck inf-looping inside `looking-at`? Is it the same place where the regexp-stack overflow happens (and with the same regexp)? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 18:49:02 2023 Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 23:49:02 +0000 Received: from localhost ([127.0.0.1]:49963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtQT-00038n-OI for submit@debbugs.gnu.org; Sun, 19 Feb 2023 18:49:02 -0500 Received: from heytings.org ([95.142.160.155]:36166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtQQ-00038d-Tt for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 18:49:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676850537; bh=vNwda1DnU1OPGmjdm95UmGntKJeSy6DGaOeTxvA/0L8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=rwgCO0Baex+WOfkRwdGTwVpvCWOUipFDrz+b5q9kzonAXyevl8xscb6tQY39hW7zQ 5FXlZ4LYTMgvkE/Y0DNcKj5xmseqxIu2Fcv5ZRr70HBMtzTrxdoLN15mrcY9e0PlTn 5cE25rgG/dzBxWEIdSdirzEBR0zMzRLVk97B2Kh3GPArpOgZOBBq5EXrO5LnxvK9ey hkAvxVkmPNOgHrSoyKdRwkxYm4ymFQwF5FHROastCSksUbVzVg+igxWolBgIzwF9nL sOSNiP0qeLulrAUSic9xb1CRvRhiG+h3tQ8C8PDNhPTGe2VuG5aSLnhOih48ApFApF G2bxMt9VLzTSw== Date: Sun, 19 Feb 2023 23:48:57 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83h6vixik1.fsf@gnu.org> Message-ID: <886c06e50e707ab83560@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > I'm not surprised. There's something weird going on there. Do you > understand the logic in this snippet near the end of > re_match_2_internal: > > /* We goto here if a matching operation fails. */ > fail: > maybe_quit (); > if (!FAIL_STACK_EMPTY ()) > { > [...] > } > else > break; /* Matching at this starting point really fails. */ > } /* for (;;) */ > > if (best_regs_set) > goto restore_best_regs; > > unbind_to (count, Qnil); > SAFE_FREE (); > > if (max_redisplay_ticks > 0 && nchars > 0) > update_redisplay_ticks (nchars / 50 + 1, NULL); > > return -1; /* Failure to match. */ > > What is the mechanism to empty the failure stack, which eventually > causes us to report a failure? What I see is that the stack is either > not being emptied, or being emptied very slowly. Do the "magic" numbers > you came up with explain that? > As Stefan just said, it's POP_FAILURE_POINT which reduces the failure stack and restarts the search (if appropriate). After more investigation (and trying to make sense of the magical numbers), my conclusion is that there is most probably no bug in the regexp engine, and that the sole culprit here is the regexp in nXML. I truncated the file to only 10k characters: it opens after a few seconds. Then I added 10k characters at a time, and opening the file took more and more time, but eventually succeeded. I stopped at 50k characters, where opening the file took something like two minutes. By extrapolation, opening the file truncated to 250k characters should take a year or so ;-) Lowering emacs_re_max_failures just makes the regexp engine fail earlier, because there is not enough room in the failure stack. In a sense it is better to fail earlier, but to do that in all cases, we would have to lower emacs_re_max_failures say to 10000, which I guess wouldn't be good because the it would fail too much. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 18:58:43 2023 Received: (at 61514) by debbugs.gnu.org; 19 Feb 2023 23:58:43 +0000 Received: from localhost ([127.0.0.1]:49978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtZr-0003Ng-HE for submit@debbugs.gnu.org; Sun, 19 Feb 2023 18:58:43 -0500 Received: from heytings.org ([95.142.160.155]:36186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtZq-0003NZ-II for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 18:58:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676851121; bh=4gjsTz6OinaryPJvolm25ocBTPiMhZ4gP68voCMXWzw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=vbwTxdf+JkVBHx15uT06SCFeutR5HrvnJUUdkXhOheVadkVYJNZGU9+Hsr0CJyboh 4z1kipYkYlFgB+AM3XheFSte9Crh7RtTtaFS7QB6VHJFFtK5WSTdax9LwkQSIFowV9 jP1gAw8gKfeBZeHdzeEqMzn5O97UxP5fHUXbPn+bSpKQwPp3cWC7SApwJDps25Ztdd tXkk21AMjuSX9oI7Xl+z50VgvEkmQMSv9GT6bhe6fbQwQDCUQOCW6orbUFyudMh9mX bUuAvyideCh31e7JjUlUjcMrKlFR1xYdrHhlavxGoSVw4bBuMndwIX504KKQCy3dKz 2OMkKxH9DaZ4w== Date: Sun, 19 Feb 2023 23:58:41 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <886c06e50e707ab83560@heytings.org> Message-ID: <886c06e50e876183758c@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > Lowering emacs_re_max_failures just makes the regexp engine fail > earlier, because there is not enough room in the failure stack. In a > sense it is better to fail earlier, but to do that in all cases, we > would have to lower emacs_re_max_failures say to 10000, which I guess > wouldn't be good because the it would fail too much. > BTW, this makes me wonder why emacs_re_max_failures is not accessible from Elisp. I think it would be very useful, if only for debugging purposes. And perhaps let-binding it to a lower value around some potentially (or actually) problematic regexps would be a good way to prevent or fix bugs such as the current one. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 19:14:37 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 00:14:37 +0000 Received: from localhost ([127.0.0.1]:49986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtpF-0003lI-2p for submit@debbugs.gnu.org; Sun, 19 Feb 2023 19:14:37 -0500 Received: from heytings.org ([95.142.160.155]:36220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTtpD-0003lA-Tt for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 19:14:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676852075; bh=PhoGFvQpZB931uFzrv0IQXizza4W29got9FtMsnV2I0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=fNbaluUSYh53LQM9S5Kks5JnACy1KiGHjtH/coRkmxWkacW2S4GhW+bUt9n8YIqRU UTNvGGNSC1hE4Eis3cU1rkQ9+dZgIKPCCrIKIVDAa5ZXCnQpL5RAYF2Ey+MnzPJLs/ bVDUfy2N/cY+Uz3JiUMYLJLdZ8CO5U59vQTTA3gpxJbcmV6ACIh5xBsS+KmvC/2Il9 lTXH7gaZYwgUJHPYyRstHr3QVYk6DDHcpLg2znkOZ6CZjTaDgQ07nIsydN+pWYgeXF Ln6AwXq3sK3A9hsH8dh884DEhIw/iN0btXtZ4hLB+dgyUNX5LVkad08Hv1KgQDrYQ6 leU+4f+xCz+gg== Date: Mon, 20 Feb 2023 00:14:34 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <886c06e50e707ab83560@heytings.org> Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > In a sense it is better to fail earlier, but to do that in all cases, we > would have to lower emacs_re_max_failures say to 10000, which I guess > wouldn't be good because the it would fail too much. > Out of curiosity, I just bootstrapped Emacs with emacs_re_max_failures = 10000. make and make check succeed, except one test: regex-repeat-limit. With emacs_re_max_failures = 19661 or higher that test succeeds. I don't know how important it is to allow x\\{65535\\}. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 21:06:04 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 02:06:04 +0000 Received: from localhost ([127.0.0.1]:50051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTvZ5-0006pm-ED for submit@debbugs.gnu.org; Sun, 19 Feb 2023 21:06:03 -0500 Received: from heytings.org ([95.142.160.155]:36308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTvZ2-0006pJ-UH for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 21:06:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676858759; bh=RKa7OEsqCKulDFRNVwCF/EW5I33hnZU4/r1/L63U4D0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=tpR535abhq0S8JkAGMT+AasOOPfpCwtFB+n6sN5vRVSgPu44YYjhpvpgviJpz5Erd 9od5oEn1fhKLn86gsBlLTp6dC7JmCfpAOMCVBG29k2+x9Ao6ZJ3wzDXmKQw3zVS3nX 5Aj0SYG0cOhR8xX5lLt2J0gDU51zWmP8KtOGoZNnWoCIYaKMs1vfd+WZ1yBTqdQzJt 49bxLu/hL5eX6HMP5w3L9Hpk6mTTJ6tyBgbQPdTw3oS8oltIOPpXyplSsMc6d0NiHO lhC9shss6xso0EMpwgmnCpNj1g/5ll+y1U180Apryi1yT5kIyOolNrhzbAOpJ8RJnG PKC2tt3m9GLcw== Date: Mon, 20 Feb 2023 02:05:59 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <886c06e50e876183758c@heytings.org> Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="TAu4gfOE4u" Content-ID: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --TAu4gfOE4u Content-Type: text/plain; charset=us-ascii; format=flowed Content-ID: >> Lowering emacs_re_max_failures just makes the regexp engine fail >> earlier, because there is not enough room in the failure stack. In a >> sense it is better to fail earlier, but to do that in all cases, we >> would have to lower emacs_re_max_failures say to 10000, which I guess >> wouldn't be good because the it would fail too much. > > BTW, this makes me wonder why emacs_re_max_failures is not accessible > from Elisp. I think it would be very useful, if only for debugging > purposes. And perhaps let-binding it to a lower value around some > potentially (or actually) problematic regexps would be a good way to > prevent or fix bugs such as the current one. > Looking at the history of that variable, which is in fact a compile-time constant, I see that it was initially (May 1995) set to 200000. A few months later (Nov 1995) it was set to 20000, and reduced again (apparently because of bug reports) to 8000 and to 4000 (both in Jun 1996). Two months later it was again set to 20000 (Aug 1996), and a year later to 40000 (Dec 1997). It kept that value since then. As these changes (and this bug report) demonstrate, it is not possible to give that variable a "one size fits all" value. Here's a patch that makes it modifiable, and "fixes" (in the sense of failing with a "Stack overflow in regexp matcher" instead of inflooping) the current bug. WDYT? --TAu4gfOE4u Content-Type: text/x-diff; name=Make-the-number-of-failure-points-in-regexp-searches.patch; charset=us-ascii Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename=Make-the-number-of-failure-points-in-regexp-searches.patch RnJvbSAwYTU4OTY5NjcwNjM3Y2I0ZjA2NWFlNjE5NTMxZjc4YTExZWE5YmRi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0 aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBNb24sIDIwIEZl YiAyMDIzIDAxOjQ3OjI4ICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug dGhlIG51bWJlciBvZiBmYWlsdXJlIHBvaW50cyBpbiByZWdleHAgc2VhcmNo ZXMNCiBtb2RpZmlhYmxlDQoNCiogc3JjL3NlYXJjaC5jIChzeW1zX29mX3Nl YXJjaCkgPHJlZ2V4cC1tYXgtZmFpbHVyZXM+OiBOZXcNCnZhcmlhYmxlLCBy ZXBsYWNpbmcgdGhlIGNvbnN0YW50IHZhcmlhYmxlICdlbWFjc19yZV9tYXhf ZmFpbHVyZXMnLg0KSW5pdGlhbGl6ZSBpdCB3aXRoIHRoZSBjb25zdGFudCAn bWF4X3JlZ2V4cF9tYXhfZmFpbHVyZScuDQoNCiogc3JjL3JlZ2V4LWVtYWNz Lmg6IFJlcGxhY2UgdGhlIGV4dGVybmFsIGRlZmluaXRpb24gb2YNCidlbWFj c19yZV9tYXhfZmFpbHVyZXMnIHdpdGggdGhlIGNvbnN0YW50DQonbWF4X3Jl Z2V4cF9tYXhfZmFpbHVyZScuDQoNCiogc3JjL3JlZ2V4LWVtYWNzLmMgKEdS T1dfRkFJTF9TVEFDSyk6IFVzZSB0aGUgbmV3IHZhcmlhYmxlDQppbnN0ZWFk IG9mIHRoZSBjb25zdGFudC4gIFJlc2V0IGl0IHRvIGl0cyBtYXhpbXVtIHZh bHVlIGlmDQpuZWNlc3NhcnkuDQoNCiogc3JjL2VtYWNzLmMgKG1haW4pOiBV c2UgdGhlIG5ldyBjb25zdGFudA0KJ21heF9yZWdleHBfbWF4X2ZhaWx1cmUn Lg0KDQoqIGxpc3AvbnhtbC94bWx0b2suZWwgKHhtbHRvay1zY2FuLWF0dHJp YnV0ZXMpOiBCaW5kDQoncmVnZXhwLW1heC1mYWlsdXJlcycgdG8gYSBzbWFs bCB2YWx1ZS4gIEZpeGVzIGJ1ZyM2MTUxNC4NCi0tLQ0KIGxpc3AvbnhtbC94 bWx0b2suZWwgfCAgMyArKy0NCiBzcmMvZW1hY3MuYyAgICAgICAgIHwgIDQg KystLQ0KIHNyYy9yZWdleC1lbWFjcy5jICAgfCAyMyArKysrKysrKy0tLS0t LS0tLS0tLS0tLQ0KIHNyYy9yZWdleC1lbWFjcy5oICAgfCAgNCArKy0tDQog c3JjL3NlYXJjaC5jICAgICAgICB8ICA0ICsrKysNCiA1IGZpbGVzIGNoYW5n ZWQsIDE4IGluc2VydGlvbnMoKyksIDIwIGRlbGV0aW9ucygtKQ0KDQpkaWZm IC0tZ2l0IGEvbGlzcC9ueG1sL3htbHRvay5lbCBiL2xpc3AvbnhtbC94bWx0 b2suZWwNCmluZGV4IGMzNmQyMjVjN2M5Li4zMmQ2ZGZkMzljMSAxMDA2NDQN Ci0tLSBhL2xpc3AvbnhtbC94bWx0b2suZWwNCisrKyBiL2xpc3AvbnhtbC94 bWx0b2suZWwNCkBAIC03MzEsNyArNzMxLDggQEAgeG1sdG9rLXNjYW4tYWZ0 ZXItY29tbWVudC1vcGVuDQogDQogKGRlZnVuIHhtbHRvay1zY2FuLWF0dHJp YnV0ZXMgKCkNCiAgIChsZXQgKChyZWNvdmVyaW5nIG5pbCkNCi0JKGF0dHMt bmVlZGluZy1ub3JtYWxpemF0aW9uIG5pbCkpDQorCShhdHRzLW5lZWRpbmct bm9ybWFsaXphdGlvbiBuaWwpDQorCShyZWdleHAtbWF4LWZhaWx1cmVzIDEw MDApKQ0KICAgICAod2hpbGUgKGNvbmQgKChvciAobG9va2luZy1hdCAoeG1s dG9rLWF0dHJpYnV0ZSByZWdleHApKQ0KIAkJICAgICAgOzsgdXNlIG5vbi1n cmVlZHkgZ3JvdXANCiAJCSAgICAgICh3aGVuIChsb29raW5nLWF0IChjb25j YXQgIltePD5cbl0rPyINCmRpZmYgLS1naXQgYS9zcmMvZW1hY3MuYyBiL3Ny Yy9lbWFjcy5jDQppbmRleCAyMTRlMmUyYTI5Ni4uZWI5NzhjOWRlMjMgMTAw NjQ0DQotLS0gYS9zcmMvZW1hY3MuYw0KKysrIGIvc3JjL2VtYWNzLmMNCkBA IC0xNDk5LDcgKzE0OTksNyBAQCBtYWluIChpbnQgYXJnYywgY2hhciAqKmFy Z3YpDQogICAgICAgcmxpbV90IGxpbSA9IHJsaW0ucmxpbV9jdXI7DQogDQog ICAgICAgLyogQXBwcm94aW1hdGUgdGhlIGFtb3VudCByZWdleC1lbWFjcy5j IG5lZWRzIHBlciB1bml0IG9mDQotCSBlbWFjc19yZV9tYXhfZmFpbHVyZXMs IHRoZW4gYWRkIDMzJSB0byBjb3ZlciB0aGUgc2l6ZSBvZiB0aGUNCisJIG1h eF9yZWdleHBfbWF4X2ZhaWx1cmVzLCB0aGVuIGFkZCAzMyUgdG8gY292ZXIg dGhlIHNpemUgb2YgdGhlDQogCSBzbWFsbGVyIHN0YWNrcyB0aGF0IHJlZ2V4 LWVtYWNzLmMgc3VjY2Vzc2l2ZWx5IGFsbG9jYXRlcyBhbmQNCiAJIGRpc2Nh cmRzIG9uIGl0cyB3YXkgdG8gdGhlIG1heGltdW0uICAqLw0KICAgICAgIGlu dCBtaW5fcmF0aW8gPSAyMCAqIHNpemVvZiAoY2hhciAqKTsNCkBAIC0xNTE0 LDcgKzE1MTQsNyBAQCBtYWluIChpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQog DQogICAgICAgaWYgKHRyeV90b19ncm93X3N0YWNrKQ0KIAl7DQotCSAgcmxp bV90IG5ld2xpbSA9IGVtYWNzX3JlX21heF9mYWlsdXJlcyAqIHJhdGlvICsg ZXh0cmE7DQorCSAgcmxpbV90IG5ld2xpbSA9IG1heF9yZWdleHBfbWF4X2Zh aWx1cmVzICogcmF0aW8gKyBleHRyYTsNCiANCiAJICAvKiBSb3VuZCB0aGUg bmV3IGxpbWl0IHRvIGEgcGFnZSBib3VuZGFyeTsgdGhpcyBpcyBuZWVkZWQN CiAJICAgICBmb3IgRGFyd2luIGtlcm5lbCAxNS40LjAgKHNlZSBCdWcjMjM2 MjIpIGFuZCBwZXJoYXBzDQpkaWZmIC0tZ2l0IGEvc3JjL3JlZ2V4LWVtYWNz LmMgYi9zcmMvcmVnZXgtZW1hY3MuYw0KaW5kZXggMmRjYTBkMTZhZDkuLjg3 ZDRkNWNkNDM0IDEwMDY0NA0KLS0tIGEvc3JjL3JlZ2V4LWVtYWNzLmMNCisr KyBiL3NyYy9yZWdleC1lbWFjcy5jDQpAQCAtODY4LDE3ICs4NjgsNiBAQCBw cmludF9kb3VibGVfc3RyaW5nIChyZV9jaGFyICp3aGVyZSwgcmVfY2hhciAq c3RyaW5nMSwgcHRyZGlmZl90IHNpemUxLA0KICAgIHNwYWNlLCBzbyBpdCBp cyBub3QgYSBoYXJkIGxpbWl0LiAgKi8NCiAjZGVmaW5lIElOSVRfRkFJTFVS RV9BTExPQyAyMA0KIA0KLS8qIFJvdWdobHkgdGhlIG1heGltdW0gbnVtYmVy IG9mIGZhaWx1cmUgcG9pbnRzIG9uIHRoZSBzdGFjay4gIFdvdWxkIGJlDQot ICAgZXhhY3RseSB0aGF0IGlmIGZhaWx1cmUgYWx3YXlzIHVzZWQgVFlQSUNB TF9GQUlMVVJFX1NJWkUgaXRlbXMuDQotICAgVGhpcyBpcyBhIHZhcmlhYmxl IG9ubHkgc28gdXNlcnMgb2YgcmVnZXggY2FuIGFzc2lnbiB0byBpdDsgd2Ug bmV2ZXINCi0gICBjaGFuZ2UgaXQgb3Vyc2VsdmVzLiAgV2UgYWx3YXlzIG11 bHRpcGx5IGl0IGJ5IFRZUElDQUxfRkFJTFVSRV9TSVpFDQotICAgYmVmb3Jl IHVzaW5nIGl0LCBzbyBpdCBzaG91bGQgcHJvYmFibHkgYmUgYSBieXRlLWNv dW50IGluc3RlYWQuICAqLw0KLS8qIE5vdGUgdGhhdCA0NDAwIHdhcyBlbm91 Z2ggdG8gY2F1c2UgYSBjcmFzaCBvbiBBbHBoYSBPU0YvMSwNCi0gICB3aG9z ZSBkZWZhdWx0IHN0YWNrIGxpbWl0IGlzIDJtYi4gIEluIG9yZGVyIGZvciBh IGxhcmdlcg0KLSAgIHZhbHVlIHRvIHdvcmsgcmVsaWFibHksIHlvdSBoYXZl IHRvIHRyeSB0byBtYWtlIGl0IGFjY29yZA0KLSAgIHdpdGggdGhlIHByb2Nl c3Mgc3RhY2sgbGltaXQuICAqLw0KLXB0cmRpZmZfdCBlbWFjc19yZV9tYXhf ZmFpbHVyZXMgPSA0MDAwMDsNCi0NCiB1bmlvbiBmYWlsX3N0YWNrX2VsdA0K IHsNCiAgIHJlX2NoYXIgKnBvaW50ZXI7DQpAQCAtOTEyLDcgKzkwMSw3IEBA ICNkZWZpbmUgSU5JVF9GQUlMX1NUQUNLKCkJCQkJCQlcDQogDQogDQogLyog RG91YmxlIHRoZSBzaXplIG9mIEZBSUxfU1RBQ0ssIHVwIHRvIGEgbGltaXQN Ci0gICB3aGljaCBhbGxvd3MgYXBwcm94aW1hdGVseSAnZW1hY3NfcmVfbWF4 X2ZhaWx1cmVzJyBpdGVtcy4NCisgICB3aGljaCBhbGxvd3MgYXBwcm94aW1h dGVseSAnVnJlZ2V4cF9tYXhfZmFpbHVyZXMnIGl0ZW1zLg0KIA0KICAgIFJl dHVybiAxIGlmIHN1Y2NlZWRzLCBhbmQgMCBpZiBlaXRoZXIgcmFuIG91dCBv ZiBtZW1vcnkNCiAgICBhbGxvY2F0aW5nIHNwYWNlIGZvciBpdCBvciBpdCB3 YXMgYWxyZWFkeSB0b28gbGFyZ2UuDQpAQCAtOTI2LDE2ICs5MTUsMjAgQEAg I2RlZmluZSBJTklUX0ZBSUxfU1RBQ0soKQkJCQkJCVwNCiAjZGVmaW5lIEZB SUxfU1RBQ0tfR1JPV1RIX0ZBQ1RPUiA0DQogDQogI2RlZmluZSBHUk9XX0ZB SUxfU1RBQ0soZmFpbF9zdGFjaykJCQkJCVwNCi0gICgoKGZhaWxfc3RhY2sp LnNpemUgPj0gZW1hY3NfcmVfbWF4X2ZhaWx1cmVzICogVFlQSUNBTF9GQUlM VVJFX1NJWkUpICAgICAgICBcDQorICAoKFZyZWdleHBfbWF4X2ZhaWx1cmVz ID0JCQkJCQlcDQorICAgIFZyZWdleHBfbWF4X2ZhaWx1cmVzIDwgMAkJCQkJ CVwNCisgICAgfHwgVnJlZ2V4cF9tYXhfZmFpbHVyZXMgPiBtYXhfcmVnZXhw X21heF9mYWlsdXJlcyA/CQkJXA0KKyAgICBtYXhfcmVnZXhwX21heF9mYWls dXJlcyA6IFZyZWdleHBfbWF4X2ZhaWx1cmVzKSwJCQlcDQorICAgKChmYWls X3N0YWNrKS5zaXplID49IFZyZWdleHBfbWF4X2ZhaWx1cmVzICogVFlQSUNB TF9GQUlMVVJFX1NJWkUpICAgXA0KICAgID8gMAkJCQkJCQkJCVwNCiAgICA6 ICgoZmFpbF9zdGFjaykuc3RhY2sJCQkJCQlcDQogICAgICAgPSBSRUdFWF9S RUFMTE9DQVRFICgoZmFpbF9zdGFjaykuc3RhY2ssCQkJCVwNCiAJICAoZmFp bF9zdGFjaykuYXZhaWwgKiBzaXplb2YgKGZhaWxfc3RhY2tfZWx0X3QpLAkJ XA0KLSAgICAgICAgICBtaW4gKGVtYWNzX3JlX21heF9mYWlsdXJlcyAqIFRZ UElDQUxfRkFJTFVSRV9TSVpFLCAgICAgICAgICAgICAgICAgIFwNCisgICAg ICAgICAgbWluIChWcmVnZXhwX21heF9mYWlsdXJlcyAqIFRZUElDQUxfRkFJ TFVSRV9TSVpFLCAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgKChm YWlsX3N0YWNrKS5zaXplICogRkFJTF9TVEFDS19HUk9XVEhfRkFDVE9SKSkg ICAgICAgICAgXA0KICAgICAgICAgICAqIHNpemVvZiAoZmFpbF9zdGFja19l bHRfdCkpLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAg ICAgICAoKGZhaWxfc3RhY2spLnNpemUJCQkJCQlcDQotICAgICAgID0gKG1p biAoZW1hY3NfcmVfbWF4X2ZhaWx1cmVzICogVFlQSUNBTF9GQUlMVVJFX1NJ WkUsCQlcDQorICAgICAgID0gKG1pbiAoVnJlZ2V4cF9tYXhfZmFpbHVyZXMg KiBUWVBJQ0FMX0ZBSUxVUkVfU0laRSwJCVwNCiAJICAgICAgICgoZmFpbF9z dGFjaykuc2l6ZSAqIEZBSUxfU1RBQ0tfR1JPV1RIX0ZBQ1RPUikpKSksCVwN CiAgICAgICAxKSkNCiANCmRpZmYgLS1naXQgYS9zcmMvcmVnZXgtZW1hY3Mu aCBiL3NyYy9yZWdleC1lbWFjcy5oDQppbmRleCAxYmM5NzMzNjNlOS4uMTZi ZDdkYTA5NGIgMTAwNjQ0DQotLS0gYS9zcmMvcmVnZXgtZW1hY3MuaA0KKysr IGIvc3JjL3JlZ2V4LWVtYWNzLmgNCkBAIC00OSw4ICs0OSw4IEBAICNkZWZp bmUgRU1BQ1NfUkVHRVhfSCAxDQogICAgVE9ETzogdHVybiBpbnRvIGFuIGFj dHVhbCBmdW5jdGlvbiBwYXJhbWV0ZXIuICAqLw0KIGV4dGVybiBMaXNwX09i amVjdCByZV9tYXRjaF9vYmplY3Q7DQogDQotLyogUm91Z2hseSB0aGUgbWF4 aW11bSBudW1iZXIgb2YgZmFpbHVyZSBwb2ludHMgb24gdGhlIHN0YWNrLiAg Ki8NCi1leHRlcm4gcHRyZGlmZl90IGVtYWNzX3JlX21heF9mYWlsdXJlczsN CisvKiBNYXhpbXVtIHZhbHVlIGZvciBWcmVnZXhwX21heF9mYWlsdXJlcy4g ICovDQorI2RlZmluZSBtYXhfcmVnZXhwX21heF9mYWlsdXJlcyA0MDAwMA0K IA0KIC8qIEFtb3VudCBvZiBtZW1vcnkgdGhhdCB3ZSBjYW4gc2FmZWx5IHN0 YWNrIGFsbG9jYXRlLiAgKi8NCiBleHRlcm4gcHRyZGlmZl90IGVtYWNzX3Jl X3NhZmVfYWxsb2NhOw0KZGlmZiAtLWdpdCBhL3NyYy9zZWFyY2guYyBiL3Ny Yy9zZWFyY2guYw0KaW5kZXggMGJiNTJjMDNlZWYuLmUzMzYwZWIzYTg2IDEw MDY0NA0KLS0tIGEvc3JjL3NlYXJjaC5jDQorKysgYi9zcmMvc2VhcmNoLmMN CkBAIC0zNDMxLDYgKzM0MzEsMTAgQEAgc3ltc19vZl9zZWFyY2ggKHZvaWQp DQogaXMgdG8gYmluZCBpdCB3aXRoIGBsZXQnIGFyb3VuZCBhIHNtYWxsIGV4 cHJlc3Npb24uICAqLyk7DQogICBWaW5oaWJpdF9jaGFuZ2luZ19tYXRjaF9k YXRhID0gUW5pbDsNCiANCisgIERFRlZBUl9JTlQgKCJyZWdleHAtbWF4LWZh aWx1cmVzIiwgVnJlZ2V4cF9tYXhfZmFpbHVyZXMsDQorCSAgICAgIGRvYzog LyogTWF4aW11bSBudW1iZXIgb2YgZmFpbHVyZXMgcG9pbnRzIGluIGEgcmVn ZXhwIHNlYXJjaC4gICovKTsNCisgIFZyZWdleHBfbWF4X2ZhaWx1cmVzID0g bWF4X3JlZ2V4cF9tYXhfZmFpbHVyZXM7DQorDQogICBkZWZzdWJyICgmU2xv b2tpbmdfYXQpOw0KICAgZGVmc3ViciAoJlNwb3NpeF9sb29raW5nX2F0KTsN CiAgIGRlZnN1YnIgKCZTc3RyaW5nX21hdGNoKTsNCi0tIA0KMi4zOS4wDQoN Cg== --TAu4gfOE4u-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 19 23:24:46 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 04:24:46 +0000 Received: from localhost ([127.0.0.1]:50134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTxjK-0001yu-5k for submit@debbugs.gnu.org; Sun, 19 Feb 2023 23:24:46 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTxjI-0001yf-IK for 61514@debbugs.gnu.org; Sun, 19 Feb 2023 23:24:45 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id ADB39100099; Sun, 19 Feb 2023 23:24:38 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 337F6100048; Sun, 19 Feb 2023 23:24:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676867077; bh=GifiqU9wZHKzBQNkkqOezTLlOO1SyQaUB3G7+wuzwXw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NMAmXupkUVseGBOAtEV6G8Xklt6ShbeZSgEL1zqutZoAyNTTx7+2crM8oa/31eJ8P xosonoK0lxsm2BfGjVEcEZ13toYWtOwOBl4X84sbZuh4R50AGUcsNneLLktOzm2TEY J08ayeOCsetP5h5CC31PhdY0M4PZq2hmCZdkGQrz9fjwGNu3ZUv8BjxUe2caRzEMtj d+1AbeHS0xAK394omhhkPENzfw+/UWLg3LbZxa7NZ0Csffk6mAcfW19RL3/iptVpWF VWzJS108XOM2y0HTGFftU6oCU+7pGd/v/cL8vmKZsupWojhEadjFgK2CH9zgk9o7yY 0pFVKTbzGNnUA== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 016771231B3; Sun, 19 Feb 2023 23:24:36 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: (Gregory Heytings's message of "Mon, 20 Feb 2023 02:05:59 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> Date: Sun, 19 Feb 2023 23:24:30 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.079 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Looking at the history of that variable, which is in fact a compile-time > constant, I see that it was initially (May 1995) set to 200000. A few > months later (Nov 1995) it was set to 20000, and reduced again (apparently > because of bug reports) to 8000 and to 4000 (both in Jun 1996). Two months > later it was again set to 20000 (Aug 1996), and a year later to 40000 (Dec > 1997). It kept that value since then. As these changes (and this bug > report) demonstrate, it is not possible to give that variable a "one size > fits all" value. Note that the stack is allocated with `SAFE_ALLOCA` and used to be allocated with just `alloca`. So the constant was probably reduced (back in the 90s) in response to reports of segfaults due to C stack overflows. Nowadays we should be hopefully(?) safe from such segfaults since `SAFE_ALLOCA` only uses `alloca` for smallish allocations. > @@ -731,7 +731,8 @@ xmltok-scan-after-comment-open > > (defun xmltok-scan-attributes () > (let ((recovering nil) > - (atts-needing-normalization nil)) > + (atts-needing-normalization nil) > + (regexp-max-failures 1000)) > (while (cond ((or (looking-at (xmltok-attribute regexp)) > ;; use non-greedy group > (when (looking-at (concat "[^<>\n]+?" This really needs a comment (at least one referring to this bug report). I think the idea is that we hope the regexp will need at most one stack entry per character, so the above means that we're willing to limit the regexp search to about 1kB of text, which sounds fair given it's supposed to match just a single XML attribute. > + DEFVAR_INT ("regexp-max-failures", Vregexp_max_failures, > + doc: /* Maximum number of failures points in a regexp search. */); > + Vregexp_max_failures = max_regexp_max_failures; This name is misleading. It suggests it's talking about how many times we fail, whereas the reality is that it's about the number of pending branches in the search space (which the source code calls "failure points" because it's info to be used in case the current branch fails to match). It could also be described as the number of "pending continuations" or "stacked failure continuations" or some wording like that. But for the var name itself, how 'bout `regexp-max-backtracking-depth`? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 06:28:49 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 11:28:49 +0000 Received: from localhost ([127.0.0.1]:50669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU4Lg-0005Ob-CT for submit@debbugs.gnu.org; Mon, 20 Feb 2023 06:28:49 -0500 Received: from heytings.org ([95.142.160.155]:36748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU4Ld-0005OS-VC for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 06:28:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676892524; bh=iO+q/4UGY7xfluBxCAYuls3349bUB4q09Y4Dq4JI8xQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=0gxmfSex8YrhYt1VY9gvOTRBp9HuinCWp7V2Zgn6/QazLT4NAOWSz8sRn6qzBdxW/ BFIoJRKyBmGJMzaa2BktrRCoy4ZjbbqT03tZUafJuN0ybNpwM8pyT7n/6GGJe1qmPf Yz/LEOdJJTQ6pOczfenRSYNTaMzV/tS5OiQHozM9CmEFAN1p7kAoERKInsUNTQ0rWH Kbml/fKbhZFAyzdTkwBy5un8p921IVa4tOxscopLpy/R0e06CPB++VZOxds/zJURjv CBQJqCs9N33O0LaGg6bibIHhBkBa9RNA9FUfxAZ7VgYYtOnYIamKhElMoTh7y9/vCs fipW6blxbwLUQ== Date: Mon, 20 Feb 2023 11:28:44 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Z1TXJaJrKj" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --Z1TXJaJrKj Content-Type: text/plain; format=flowed; charset=us-ascii >> Looking at the history of that variable, which is in fact a >> compile-time constant, I see that it was initially (May 1995) set to >> 200000. A few months later (Nov 1995) it was set to 20000, and reduced >> again (apparently because of bug reports) to 8000 and to 4000 (both in >> Jun 1996). Two months later it was again set to 20000 (Aug 1996), and >> a year later to 40000 (Dec 1997). It kept that value since then. As >> these changes (and this bug report) demonstrate, it is not possible to >> give that variable a "one size fits all" value. > > Note that the stack is allocated with `SAFE_ALLOCA` and used to be > allocated with just `alloca`. So the constant was probably reduced > (back in the 90s) in response to reports of segfaults due to C stack > overflows. > Indeed. But now that we use SAFE_ALLOCA, we fallback to malloc when there is not enough room for an alloca, so the constant seems even more arbitrary. > > Nowadays we should be hopefully(?) safe from such segfaults since > `SAFE_ALLOCA` only uses `alloca` for smallish allocations. > That's not the case in regex-emacs.c: REGEX_USE_SAFE_ALLOCA sets sa_avail to emacs_re_safe_alloca (~6 MiB) instead of its default MAX_ALLOCA value (16 KiB). > > This really needs a comment (at least one referring to this bug report). > I think the idea is that we hope the regexp will need at most one stack > entry per character, so the above means that we're willing to limit the > regexp search to about 1kB of text, which sounds fair given it's > supposed to match just a single XML attribute. > Indeed, thanks! >> + DEFVAR_INT ("regexp-max-failures", Vregexp_max_failures, >> + doc: /* Maximum number of failures points in a regexp search. */); >> + Vregexp_max_failures = max_regexp_max_failures; > > This name is misleading. It suggests it's talking about how many times > we fail, whereas the reality is that it's about the number of pending > branches in the search space (which the source code calls "failure > points" because it's info to be used in case the current branch fails to > match). It could also be described as the number of "pending > continuations" or "stacked failure continuations" or some wording like > that. > > But for the var name itself, how 'bout `regexp-max-backtracking-depth`? > Indeed again, and thanks again! Updated patch attached. --Z1TXJaJrKj Content-Type: text/x-diff; name=Make-the-backtracking-depth-of-regexp-searches-modif.patch Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename=Make-the-backtracking-depth-of-regexp-searches-modif.patch RnJvbSA0NTIzMzg3YWM2NDVkOGQ2ZGFhYjA3MTE0ZTI5ZDkzODZhMDI0NTBh IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0 aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBNb24sIDIwIEZl YiAyMDIzIDExOjE4OjMwICswMDAwDQpTdWJqZWN0OiBbUEFUQ0hdIE1ha2Ug dGhlIGJhY2t0cmFja2luZyBkZXB0aCBvZiByZWdleHAgc2VhcmNoZXMgbW9k aWZpYWJsZQ0KDQoqIHNyYy9zZWFyY2guYyAoc3ltc19vZl9zZWFyY2gpIDxy ZWdleHAtbWF4LWJhY2t0cmFja2luZy1kZXB0aD46DQpOZXcgdmFyaWFibGUs IHJlcGxhY2luZyB0aGUgY29uc3RhbnQgdmFyaWFibGUNCidlbWFjc19yZV9t YXhfZmFpbHVyZXMnLiAgSW5pdGlhbGl6ZSBpdCB3aXRoIHRoZSBjb25zdGFu dA0KJ21heF9yZWdleHBfbWF4X2JhY2t0cmFja2luZ19kZXB0aCcuDQoNCiog c3JjL3JlZ2V4LWVtYWNzLmg6IFJlcGxhY2UgdGhlIGV4dGVybmFsIGRlZmlu aXRpb24gb2YNCidlbWFjc19yZV9tYXhfZmFpbHVyZXMnIHdpdGggdGhlIGNv bnN0YW50DQonbWF4X3JlZ2V4cF9tYXhfYmFja3RyYWNraW5nX2RlcHRoJy4N Cg0KKiBzcmMvcmVnZXgtZW1hY3MuYyAoR1JPV19GQUlMX1NUQUNLKTogVXNl IHRoZSBuZXcgdmFyaWFibGUNCmluc3RlYWQgb2YgdGhlIGNvbnN0YW50LiAg UmVzZXQgaXQgdG8gaXRzIG1heGltdW0gdmFsdWUgd2hlbg0KbmVjZXNzYXJ5 Lg0KDQoqIHNyYy9lbWFjcy5jIChtYWluKTogVXNlIHRoZSBuZXcgY29uc3Rh bnQNCidtYXhfcmVnZXhwX21heF9iYWNrdHJhY2tpbmdfZGVwdGgnIGluIHRo ZSBjYWxjdWxhdGlvbnMuDQoNCiogbGlzcC9ueG1sL3htbHRvay5lbCAoeG1s dG9rLXNjYW4tYXR0cmlidXRlcyk6IEJpbmQNCidyZWdleHAtbWF4LWJhY2t0 cmFja2luZy1kZXB0aCcgdG8gYSBzbWFsbCB2YWx1ZSwgYW5kIGFkZCBhDQpj b21tZW50LiAgRml4ZXMgYnVnIzYxNTE0Lg0KLS0tDQogbGlzcC9ueG1sL3ht bHRvay5lbCB8ICA3ICsrKysrKy0NCiBzcmMvZW1hY3MuYyAgICAgICAgIHwg IDggKysrKy0tLS0NCiBzcmMvcmVnZXgtZW1hY3MuYyAgIHwgMjYgKysrKysr KysrKystLS0tLS0tLS0tLS0tLS0NCiBzcmMvcmVnZXgtZW1hY3MuaCAgIHwg IDcgKysrKystLQ0KIHNyYy9zZWFyY2guYyAgICAgICAgfCAxMyArKysrKysr KysrKysrDQogNSBmaWxlcyBjaGFuZ2VkLCAzOSBpbnNlcnRpb25zKCspLCAy MiBkZWxldGlvbnMoLSkNCg0KZGlmZiAtLWdpdCBhL2xpc3AvbnhtbC94bWx0 b2suZWwgYi9saXNwL254bWwveG1sdG9rLmVsDQppbmRleCBjMzZkMjI1Yzdj OS4uODIwMWI3NzNlMGYgMTAwNjQ0DQotLS0gYS9saXNwL254bWwveG1sdG9r LmVsDQorKysgYi9saXNwL254bWwveG1sdG9rLmVsDQpAQCAtNzMxLDcgKzcz MSwxMiBAQCB4bWx0b2stc2Nhbi1hZnRlci1jb21tZW50LW9wZW4NCiANCiAo ZGVmdW4geG1sdG9rLXNjYW4tYXR0cmlidXRlcyAoKQ0KICAgKGxldCAoKHJl Y292ZXJpbmcgbmlsKQ0KLQkoYXR0cy1uZWVkaW5nLW5vcm1hbGl6YXRpb24g bmlsKSkNCisJKGF0dHMtbmVlZGluZy1ub3JtYWxpemF0aW9uIG5pbCkNCisg ICAgICAgIDs7IExpbWl0IHRoZSBiYWNrdHJhY2tpbmcgZGVwdGggb2YgcmVn ZXhwIHNlYXJjaGVzLCB0byBmYWlsDQorICAgICAgICA7OyB3aXRoIGEgIlN0 YWNrIG92ZXJmbG93IGluIHJlZ2V4cCBtYXRjaGVyIiBlcnJvciBpbnN0ZWFk IG9mDQorICAgICAgICA7OyBpbmZsb29waW5nIGluIGxvb2tpbmctYXQuICBU aGlzIGFzc3VtZXMgdGhhdCBYTUwgYXR0cmlidXRlcw0KKyAgICAgICAgOzsg ZG8gbm90IHVzZSBtb3JlIHRoYW4gYWJvdXQgMSBLQiBjaGFyYWN0ZXJzLiAg U2VlIGJ1ZyM2MTUxNC4NCisJKHJlZ2V4cC1tYXgtYmFja3RyYWNraW5nLWRl cHRoIDEwMDApKQ0KICAgICAod2hpbGUgKGNvbmQgKChvciAobG9va2luZy1h dCAoeG1sdG9rLWF0dHJpYnV0ZSByZWdleHApKQ0KIAkJICAgICAgOzsgdXNl IG5vbi1ncmVlZHkgZ3JvdXANCiAJCSAgICAgICh3aGVuIChsb29raW5nLWF0 IChjb25jYXQgIltePD5cbl0rPyINCmRpZmYgLS1naXQgYS9zcmMvZW1hY3Mu YyBiL3NyYy9lbWFjcy5jDQppbmRleCAyMTRlMmUyYTI5Ni4uZDBkY2EzZjAz ZWMgMTAwNjQ0DQotLS0gYS9zcmMvZW1hY3MuYw0KKysrIGIvc3JjL2VtYWNz LmMNCkBAIC0xNDk5LDkgKzE0OTksOSBAQCBtYWluIChpbnQgYXJnYywgY2hh ciAqKmFyZ3YpDQogICAgICAgcmxpbV90IGxpbSA9IHJsaW0ucmxpbV9jdXI7 DQogDQogICAgICAgLyogQXBwcm94aW1hdGUgdGhlIGFtb3VudCByZWdleC1l bWFjcy5jIG5lZWRzIHBlciB1bml0IG9mDQotCSBlbWFjc19yZV9tYXhfZmFp bHVyZXMsIHRoZW4gYWRkIDMzJSB0byBjb3ZlciB0aGUgc2l6ZSBvZiB0aGUN Ci0JIHNtYWxsZXIgc3RhY2tzIHRoYXQgcmVnZXgtZW1hY3MuYyBzdWNjZXNz aXZlbHkgYWxsb2NhdGVzIGFuZA0KLQkgZGlzY2FyZHMgb24gaXRzIHdheSB0 byB0aGUgbWF4aW11bS4gICovDQorCSBtYXhfcmVnZXhwX21heF9iYWNrdHJh Y2tpbmdfZGVwdGgsIHRoZW4gYWRkIDMzJSB0byBjb3ZlciB0aGUNCisJIHNp emUgb2YgdGhlIHNtYWxsZXIgc3RhY2tzIHRoYXQgcmVnZXgtZW1hY3MuYyBz dWNjZXNzaXZlbHkNCisJIGFsbG9jYXRlcyBhbmQgZGlzY2FyZHMgb24gaXRz IHdheSB0byB0aGUgbWF4aW11bS4gICovDQogICAgICAgaW50IG1pbl9yYXRp byA9IDIwICogc2l6ZW9mIChjaGFyICopOw0KICAgICAgIGludCByYXRpbyA9 IG1pbl9yYXRpbyArIG1pbl9yYXRpbyAvIDM7DQogDQpAQCAtMTUxNCw3ICsx NTE0LDcgQEAgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQ0KIA0KICAg ICAgIGlmICh0cnlfdG9fZ3Jvd19zdGFjaykNCiAJew0KLQkgIHJsaW1fdCBu ZXdsaW0gPSBlbWFjc19yZV9tYXhfZmFpbHVyZXMgKiByYXRpbyArIGV4dHJh Ow0KKwkgIHJsaW1fdCBuZXdsaW0gPSBtYXhfcmVnZXhwX21heF9iYWNrdHJh Y2tpbmdfZGVwdGggKiByYXRpbyArIGV4dHJhOw0KIA0KIAkgIC8qIFJvdW5k IHRoZSBuZXcgbGltaXQgdG8gYSBwYWdlIGJvdW5kYXJ5OyB0aGlzIGlzIG5l ZWRlZA0KIAkgICAgIGZvciBEYXJ3aW4ga2VybmVsIDE1LjQuMCAoc2VlIEJ1 ZyMyMzYyMikgYW5kIHBlcmhhcHMNCmRpZmYgLS1naXQgYS9zcmMvcmVnZXgt ZW1hY3MuYyBiL3NyYy9yZWdleC1lbWFjcy5jDQppbmRleCAyZGNhMGQxNmFk OS4uOTMxZGI5ODBlMzkgMTAwNjQ0DQotLS0gYS9zcmMvcmVnZXgtZW1hY3Mu Yw0KKysrIGIvc3JjL3JlZ2V4LWVtYWNzLmMNCkBAIC04NjgsMTcgKzg2OCw2 IEBAIHByaW50X2RvdWJsZV9zdHJpbmcgKHJlX2NoYXIgKndoZXJlLCByZV9j aGFyICpzdHJpbmcxLCBwdHJkaWZmX3Qgc2l6ZTEsDQogICAgc3BhY2UsIHNv IGl0IGlzIG5vdCBhIGhhcmQgbGltaXQuICAqLw0KICNkZWZpbmUgSU5JVF9G QUlMVVJFX0FMTE9DIDIwDQogDQotLyogUm91Z2hseSB0aGUgbWF4aW11bSBu dW1iZXIgb2YgZmFpbHVyZSBwb2ludHMgb24gdGhlIHN0YWNrLiAgV291bGQg YmUNCi0gICBleGFjdGx5IHRoYXQgaWYgZmFpbHVyZSBhbHdheXMgdXNlZCBU WVBJQ0FMX0ZBSUxVUkVfU0laRSBpdGVtcy4NCi0gICBUaGlzIGlzIGEgdmFy aWFibGUgb25seSBzbyB1c2VycyBvZiByZWdleCBjYW4gYXNzaWduIHRvIGl0 OyB3ZSBuZXZlcg0KLSAgIGNoYW5nZSBpdCBvdXJzZWx2ZXMuICBXZSBhbHdh eXMgbXVsdGlwbHkgaXQgYnkgVFlQSUNBTF9GQUlMVVJFX1NJWkUNCi0gICBi ZWZvcmUgdXNpbmcgaXQsIHNvIGl0IHNob3VsZCBwcm9iYWJseSBiZSBhIGJ5 dGUtY291bnQgaW5zdGVhZC4gICovDQotLyogTm90ZSB0aGF0IDQ0MDAgd2Fz IGVub3VnaCB0byBjYXVzZSBhIGNyYXNoIG9uIEFscGhhIE9TRi8xLA0KLSAg IHdob3NlIGRlZmF1bHQgc3RhY2sgbGltaXQgaXMgMm1iLiAgSW4gb3JkZXIg Zm9yIGEgbGFyZ2VyDQotICAgdmFsdWUgdG8gd29yayByZWxpYWJseSwgeW91 IGhhdmUgdG8gdHJ5IHRvIG1ha2UgaXQgYWNjb3JkDQotICAgd2l0aCB0aGUg cHJvY2VzcyBzdGFjayBsaW1pdC4gICovDQotcHRyZGlmZl90IGVtYWNzX3Jl X21heF9mYWlsdXJlcyA9IDQwMDAwOw0KLQ0KIHVuaW9uIGZhaWxfc3RhY2tf ZWx0DQogew0KICAgcmVfY2hhciAqcG9pbnRlcjsNCkBAIC05MTIsNyArOTAx LDcgQEAgI2RlZmluZSBJTklUX0ZBSUxfU1RBQ0soKQkJCQkJCVwNCiANCiAN CiAvKiBEb3VibGUgdGhlIHNpemUgb2YgRkFJTF9TVEFDSywgdXAgdG8gYSBs aW1pdA0KLSAgIHdoaWNoIGFsbG93cyBhcHByb3hpbWF0ZWx5ICdlbWFjc19y ZV9tYXhfZmFpbHVyZXMnIGl0ZW1zLg0KKyAgIHdoaWNoIGFsbG93cyBhcHBy b3hpbWF0ZWx5ICdWcmVnZXhwX21heF9iYWNrdHJhY2tpbmdfZGVwdGgnIGl0 ZW1zLg0KIA0KICAgIFJldHVybiAxIGlmIHN1Y2NlZWRzLCBhbmQgMCBpZiBl aXRoZXIgcmFuIG91dCBvZiBtZW1vcnkNCiAgICBhbGxvY2F0aW5nIHNwYWNl IGZvciBpdCBvciBpdCB3YXMgYWxyZWFkeSB0b28gbGFyZ2UuDQpAQCAtOTI2 LDE2ICs5MTUsMjMgQEAgI2RlZmluZSBJTklUX0ZBSUxfU1RBQ0soKQkJCQkJ CVwNCiAjZGVmaW5lIEZBSUxfU1RBQ0tfR1JPV1RIX0ZBQ1RPUiA0DQogDQog I2RlZmluZSBHUk9XX0ZBSUxfU1RBQ0soZmFpbF9zdGFjaykJCQkJCVwNCi0g ICgoKGZhaWxfc3RhY2spLnNpemUgPj0gZW1hY3NfcmVfbWF4X2ZhaWx1cmVz ICogVFlQSUNBTF9GQUlMVVJFX1NJWkUpICAgICAgICBcDQorICAoKFZyZWdl eHBfbWF4X2JhY2t0cmFja2luZ19kZXB0aCA9CQkJCQlcDQorICAgIFZyZWdl eHBfbWF4X2JhY2t0cmFja2luZ19kZXB0aCA8PSAwCQkJCQlcDQorICAgIHx8 IFZyZWdleHBfbWF4X2JhY2t0cmFja2luZ19kZXB0aAkJCQkJXA0KKyAgICAg ICA+IG1heF9yZWdleHBfbWF4X2JhY2t0cmFja2luZ19kZXB0aAkJCQlcDQor ICAgID8gbWF4X3JlZ2V4cF9tYXhfYmFja3RyYWNraW5nX2RlcHRoCQkJCQlc DQorICAgIDogVnJlZ2V4cF9tYXhfYmFja3RyYWNraW5nX2RlcHRoKSwJCQkJ CVwNCisgICAoKGZhaWxfc3RhY2spLnNpemUJCQkJCQkJXA0KKyAgICA+PSBW cmVnZXhwX21heF9iYWNrdHJhY2tpbmdfZGVwdGggKiBUWVBJQ0FMX0ZBSUxV UkVfU0laRSkJCVwNCiAgICA/IDAJCQkJCQkJCQlcDQogICAgOiAoKGZhaWxf c3RhY2spLnN0YWNrCQkJCQkJXA0KICAgICAgID0gUkVHRVhfUkVBTExPQ0FU RSAoKGZhaWxfc3RhY2spLnN0YWNrLAkJCQlcDQogCSAgKGZhaWxfc3RhY2sp LmF2YWlsICogc2l6ZW9mIChmYWlsX3N0YWNrX2VsdF90KSwJCVwNCi0gICAg ICAgICAgbWluIChlbWFjc19yZV9tYXhfZmFpbHVyZXMgKiBUWVBJQ0FMX0ZB SUxVUkVfU0laRSwgICAgICAgICAgICAgICAgICBcDQorICAgICAgICAgIG1p biAoVnJlZ2V4cF9tYXhfYmFja3RyYWNraW5nX2RlcHRoICogVFlQSUNBTF9G QUlMVVJFX1NJWkUsICAgXA0KICAgICAgICAgICAgICAgICgoZmFpbF9zdGFj aykuc2l6ZSAqIEZBSUxfU1RBQ0tfR1JPV1RIX0ZBQ1RPUikpICAgICAgICAg IFwNCiAgICAgICAgICAgKiBzaXplb2YgKGZhaWxfc3RhY2tfZWx0X3QpKSwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcDQogICAgICAgKChm YWlsX3N0YWNrKS5zaXplCQkJCQkJXA0KLSAgICAgICA9IChtaW4gKGVtYWNz X3JlX21heF9mYWlsdXJlcyAqIFRZUElDQUxfRkFJTFVSRV9TSVpFLAkJXA0K KyAgICAgICA9IChtaW4gKFZyZWdleHBfbWF4X2JhY2t0cmFja2luZ19kZXB0 aCAqIFRZUElDQUxfRkFJTFVSRV9TSVpFLAlcDQogCSAgICAgICAoKGZhaWxf c3RhY2spLnNpemUgKiBGQUlMX1NUQUNLX0dST1dUSF9GQUNUT1IpKSkpLAlc DQogICAgICAgMSkpDQogDQpkaWZmIC0tZ2l0IGEvc3JjL3JlZ2V4LWVtYWNz LmggYi9zcmMvcmVnZXgtZW1hY3MuaA0KaW5kZXggMWJjOTczMzYzZTkuLjlj Y2M0MTc3NDg3IDEwMDY0NA0KLS0tIGEvc3JjL3JlZ2V4LWVtYWNzLmgNCisr KyBiL3NyYy9yZWdleC1lbWFjcy5oDQpAQCAtNDksOCArNDksMTEgQEAgI2Rl ZmluZSBFTUFDU19SRUdFWF9IIDENCiAgICBUT0RPOiB0dXJuIGludG8gYW4g YWN0dWFsIGZ1bmN0aW9uIHBhcmFtZXRlci4gICovDQogZXh0ZXJuIExpc3Bf T2JqZWN0IHJlX21hdGNoX29iamVjdDsNCiANCi0vKiBSb3VnaGx5IHRoZSBt YXhpbXVtIG51bWJlciBvZiBmYWlsdXJlIHBvaW50cyBvbiB0aGUgc3RhY2su ICAqLw0KLWV4dGVybiBwdHJkaWZmX3QgZW1hY3NfcmVfbWF4X2ZhaWx1cmVz Ow0KKy8qIE1heGltdW0gdmFsdWUgZm9yIFZyZWdleHBfbWF4X2JhY2t0cmFj a2luZ19kZXB0aC4gIFRoaXMgaXMgcm91Z2hseQ0KKyAgIHRoZSBtYXhpbXVt IGFsbG93ZWQgbnVtYmVyIG9mIGZhaWx1cmUgcG9pbnRzIG9uIHRoZSBzdGFj ay4gIEl0DQorICAgd291bGQgYmUgZXhhY3RseSB0aGF0IGlmIGZhaWx1cmUg YWx3YXlzIHVzZWQgVFlQSUNBTF9GQUlMVVJFX1NJWkUNCisgICBpdGVtcy4g ICovDQorI2RlZmluZSBtYXhfcmVnZXhwX21heF9iYWNrdHJhY2tpbmdfZGVw dGggNDAwMDANCiANCiAvKiBBbW91bnQgb2YgbWVtb3J5IHRoYXQgd2UgY2Fu IHNhZmVseSBzdGFjayBhbGxvY2F0ZS4gICovDQogZXh0ZXJuIHB0cmRpZmZf dCBlbWFjc19yZV9zYWZlX2FsbG9jYTsNCmRpZmYgLS1naXQgYS9zcmMvc2Vh cmNoLmMgYi9zcmMvc2VhcmNoLmMNCmluZGV4IDBiYjUyYzAzZWVmLi5mYzVk N2MyYjhlMiAxMDA2NDQNCi0tLSBhL3NyYy9zZWFyY2guYw0KKysrIGIvc3Jj L3NlYXJjaC5jDQpAQCAtMzQzMSw2ICszNDMxLDE5IEBAIHN5bXNfb2Zfc2Vh cmNoICh2b2lkKQ0KIGlzIHRvIGJpbmQgaXQgd2l0aCBgbGV0JyBhcm91bmQg YSBzbWFsbCBleHByZXNzaW9uLiAgKi8pOw0KICAgVmluaGliaXRfY2hhbmdp bmdfbWF0Y2hfZGF0YSA9IFFuaWw7DQogDQorICBERUZWQVJfSU5UICgicmVn ZXhwLW1heC1iYWNrdHJhY2tpbmctZGVwdGgiLCBWcmVnZXhwX21heF9iYWNr dHJhY2tpbmdfZGVwdGgsDQorCSAgICAgIGRvYzogLyogTWF4aW11bSBiYWNr dHJhY2tpbmcgZGVwdGggaW4gYSByZWdleHAgc2VhcmNoLg0KKw0KK1doZW4g dGhlIG51bWJlciBvZiBwZW5kaW5nIGJyYW5jaGVzIGluIHRoZSBzZWFyY2gg c3BhY2UgcmVhY2hlcyB0aGF0DQordGhyZXNob2xkLCBhIHJlZ2V4cCBzZWFy Y2ggZmFpbHMgd2l0aCBhICJTdGFjayBvdmVyZmxvdyBpbiByZWdleHANCitt YXRjaGVyIi4gIFJvdWdobHkgc3BlYWtpbmcsIHRoaXMgaXMgdGhlIG51bWJl ciBvZiBjaGFyYWN0ZXJzIHRvIHdoaWNoDQorYSByZWdleHAgc2VhcmNoIGlz IGxpbWl0ZWQsIHdpdGggYSBjb21wbGV4IGVub3VnaCByZWdleHAuDQorDQor Tm90ZSB0aGF0IHRoaXMgdmFyaWFibGUgd2lsbCBiZSByZXNldCB0byBpdHMg ZGVmYXVsdCB2YWx1ZSBpZiBpdCBpcw0KK3NldCB0byBhIG5vbi1wb3NpdGl2 ZSB2YWx1ZSwgb3IgdG8gYSBoaWdoZXIgdmFsdWUgdGhhbiBpdHMgZGVmYXVs dA0KK3ZhbHVlLiAgKi8pOw0KKyAgVnJlZ2V4cF9tYXhfYmFja3RyYWNraW5n X2RlcHRoID0gbWF4X3JlZ2V4cF9tYXhfYmFja3RyYWNraW5nX2RlcHRoOw0K Kw0KICAgZGVmc3ViciAoJlNsb29raW5nX2F0KTsNCiAgIGRlZnN1YnIgKCZT cG9zaXhfbG9va2luZ19hdCk7DQogICBkZWZzdWJyICgmU3N0cmluZ19tYXRj aCk7DQotLSANCjIuMzkuMA0KDQo= --Z1TXJaJrKj-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 07:19:18 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 12:19:18 +0000 Received: from localhost ([127.0.0.1]:50798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU58Y-0006ta-AH for submit@debbugs.gnu.org; Mon, 20 Feb 2023 07:19:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU58V-0006tL-QM for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 07:19:17 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU58Q-0002JX-BP; Mon, 20 Feb 2023 07:19:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GNM0GAddUPYkXc74TXn7a7IHa1bXOanQ7akkjaDD2gI=; b=qibNNwGWYWaV U4tKvz8T4rAE8oEPaRXBKSz9LhbYYcadOGzQEYApggKsWer0qDo/N8lvReQsPtylr8OOhygb0fH1Y mGSi3pxh96OftmFsMQNidTBWiwNJt5d3PHtHcZ4y20tPw7hHD0oaj4Fd+bvaABrWH/6CfdXZnoVwA aJ5CFzLHdathCbXsTF27wn0umgnqgSngZfF5mMkNCE4IKvQF09SE7HbHKcY9C/rAOpEgbCQktMP1m XICVWwOCRwKqn9tU9nWFiDdRTuS27LJ7sLdHvy0wMhRsONcpzkQigijxjPHzrOosDX0YBSG1iV1oQ YNcanSH0CFBVgsuhP4q4Ew==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU58P-0000Gi-OI; Mon, 20 Feb 2023 07:19:10 -0500 Date: Mon, 20 Feb 2023 14:19:18 +0200 Message-Id: <831qmkwmux.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 19 Feb 2023 18:48:43 -0500) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: "Mark A. Hershberger" , 61514@debbugs.gnu.org > Date: Sun, 19 Feb 2023 18:48:43 -0500 > > > The problem is in the combination of nxml-mode and some subtle > > bug/misfeature in our regexp routines. Specifically, when we overflow > > the fail stack, we fail to recover in this case, and seem to infloop > > inside re_match_2_internal, or maybe recover very inefficiently (I > > waited for almost 1 hour before giving up). The call which causes the > > loop is in xmltok.el, in the indicated line: > > > > (defun xmltok-scan-attributes () > > (let ((recovering nil) > > (atts-needing-normalization nil)) > > (while (cond ((or (looking-at (xmltok-attribute regexp)) > > ;; use non-greedy group > > (when (looking-at (concat "[^<>\n]+?" <<<<<<<<<<<<<<<<< > > (xmltok-attribute regexp))) > > (unless recovering > > (xmltok-add-error "Malformed attribute" > > (point) > > (save-excursion > > (goto-char (xmltok-attribute start > > name)) > > (skip-chars-backward "\r\n\t ") > > (point)))) > > t)) > > > > The regexp that causes this is as follows: > > > > "[^<>\n]+?\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" > > IIUC the above describes the code where we're stuck inf-looping inside > `looking-at`? Not inflooping, but very slowly backtracking, or so it seems. > Is it the same place where the regexp-stack overflow happens (and with > the same regexp)? It's (almost) the same place, but not the same regexp. The regexp which causes the stack-overflow message (which is emitted from set-auto-mode, before entering redisplay) is this: "\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" As you can see, the prepended "[^<>\n]+?" in the regexp which "hangs" makes all the difference. So the looking-at which fails reasonably quickly is the first call to looking-at above, whereas the one the "hangs" is the second one. Maybe this points out a way out of this misery? From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 07:31:13 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 12:31:13 +0000 Received: from localhost ([127.0.0.1]:50817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5K3-00019H-02 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 07:31:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55280) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5Jy-00018n-5F for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 07:31:09 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5Js-0004Qw-33; Mon, 20 Feb 2023 07:31:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xJPEBVxYQufwxhk/WqbflzM6a3ub656QWpO/Z65nHOc=; b=m5LNQOtsUeFW HlAynaJSuiTNXq8s00I6xG6WnrSGJ5ugnkFmaFReoET1dr2uG/Nom/Y6fJLycewu62xGNRzWapv7j lNcF6G4pnLY8qDbbpx7q0Us7h0CX9laL0RWWQ2lFLHCLM1aQYEu/jqVVoHJFGIeAgi4Db6Hd5or8f q/0ZkI5T7H8CDNg5RNzjmV3b7HaugJsns1veqiOZ/5XiGp3/MOqsHeohn6Q3cSGNHTfhsc3SomsDM YkY3KJeAI/8wBAxW6b1pPlv4r03WvF8xsTiNVyLaXgjvrx2SgmlijHHJwxu2epyrK66Ow3X5/0I7K 6p9QhQbQOsZRGKii9NKdIA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5Jr-0003ZV-Ay; Mon, 20 Feb 2023 07:30:59 -0500 Date: Mon, 20 Feb 2023 14:31:07 +0200 Message-Id: <83zg98v7qs.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <886c06e50e876183758c@heytings.org> (message from Gregory Heytings on Sun, 19 Feb 2023 23:58:41 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 19 Feb 2023 23:58:41 +0000 > From: Gregory Heytings > cc: mah@everybody.org, 61514@debbugs.gnu.org, > Stefan Monnier > > BTW, this makes me wonder why emacs_re_max_failures is not accessible from > Elisp. I think it would be very useful, if only for debugging purposes. > And perhaps let-binding it to a lower value around some potentially (or > actually) problematic regexps would be a good way to prevent or fix bugs > such as the current one. If we know which regexps cause problems, shouldn't we instead fix those regexps, or change how we use them? For debugging purposes, you can set the value in the debugger after starting Emacs, or with a breakpoint just before calling the problematic code. As you have seen from the history of this value, it's problematic to calculate, and the meaning of the value is not obvious. So exposing this to Lisp would be a rope that's too long to give our users and programmers. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 07:32:25 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 12:32:25 +0000 Received: from localhost ([127.0.0.1]:50822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5LF-0001BC-9n for submit@debbugs.gnu.org; Mon, 20 Feb 2023 07:32:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5LD-0001Az-2O for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 07:32:23 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5L7-0004XP-Mq; Mon, 20 Feb 2023 07:32:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nl5on0/uVp/9CY9x8kWpAQ/AvwM/p8tfFqmYpn4+x2E=; b=Yzo3GoWKLhbs AU6zV7V36EAlokZtKdkK7hkXS4tzZdoOkAcRqcSRvNqmi+5bgG0pcMVh5BmBX2WU2yW3ylI5+2H7L A95fUXoEZXjvLfHGSIdqh98R70cWB23d0SFKC2gLyTv0jauT4Dr6P1aCgoNL4eCIeFZxRtOcTSX48 azbyuVZ8xbr8AfTt78OjYGwXgC3c/rX3dBXPv6cIgw3H04SDe//UvvH4PZI1EIXNsAQZRqTbGkSnC t997EJcoPBfvGBkHDrJUXivrBPHPnKzDNTXEN9IghjB2u0lRNjqMPLpnJhlPR4Jae9WbmfaMvdNm4 CCATOQTg2083+QzD7SjNQA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5L7-0006fl-6o; Mon, 20 Feb 2023 07:32:17 -0500 Date: Mon, 20 Feb 2023 14:32:25 +0200 Message-Id: <83y1osv7om.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (message from Gregory Heytings on Mon, 20 Feb 2023 00:14:34 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 20 Feb 2023 00:14:34 +0000 > From: Gregory Heytings > cc: mah@everybody.org, 61514@debbugs.gnu.org, > Stefan Monnier > > Out of curiosity, I just bootstrapped Emacs with emacs_re_max_failures = > 10000. make and make check succeed, except one test: regex-repeat-limit. > > With emacs_re_max_failures = 19661 or higher that test succeeds. I don't > know how important it is to allow x\\{65535\\}. It makes little sense to me to limit legitimate uses of regexps because of a single pathological use case. It's the tail wagging the dog in my book. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 07:33:24 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 12:33:24 +0000 Received: from localhost ([127.0.0.1]:50827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5MB-0001Cp-N1 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 07:33:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5MA-0001Ce-K6 for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 07:33:23 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5M5-0004fo-CJ; Mon, 20 Feb 2023 07:33:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1uF+8NRtdrp1Mg6+sZhwuwC9iV6fu5VY2oWMp5xeeRI=; b=BG7KckvW92Ku 72EPbHyxHGUw6CZWOykX93tvUUkq/zyUlBGHsjMeBL6qPKkzFC1RcFBlI9YHsL+ATX8EpcASfHU7R Oa68j0kbTP/Jqn6+KsZs7grBcQP0WB5o8aLtTCtL4T/p+vPbLniWJZGiEq/a6WHwMy/2gD9ANgXlx g8TQBhCj84B5b8ZMVy4CLqcrHNu6p0sHy40k/fh4dSLkc2mqnVFlqx/lGGjFkAeT3sHfAHv0Jog2e Iug2znCv+BNN6Wul4DIFp7QGyepu1fBCfhK9rn4Rss28z5KZlYeqcw0V7HXEIYssYxexIn2XQw/je z9ls8JViDUTd0+R5RhQSQw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5M4-0005LQ-M3; Mon, 20 Feb 2023 07:33:17 -0500 Date: Mon, 20 Feb 2023 14:33:25 +0200 Message-Id: <83wn4cv7my.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (message from Gregory Heytings on Mon, 20 Feb 2023 02:05:59 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 20 Feb 2023 02:05:59 +0000 > From: Gregory Heytings > cc: mah@everybody.org, 61514@debbugs.gnu.org, > Stefan Monnier > > Here's a patch that makes it modifiable, and "fixes" (in the sense of > failing with a "Stack overflow in regexp matcher" instead of inflooping) > the current bug. > > WDYT? I'm against it. I'd rather try to fix what nXML does and/or the regexp it uses. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 07:40:58 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 12:40:58 +0000 Received: from localhost ([127.0.0.1]:50846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5TV-0001OJ-QA for submit@debbugs.gnu.org; Mon, 20 Feb 2023 07:40:58 -0500 Received: from heytings.org ([95.142.160.155]:36856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5TU-0001OA-1f for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 07:40:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676896855; bh=fH9LmQB5CCNfZQ1xC+pIAIEj0DqTY8YGL9YEqY0NbKg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=0/OlBLSgJR9qpq+P+GUUcapye6S+N93ajUagWbhSKBGelEfVXIa+Ny5+DmElcgBo/ PF/POqMxvgBcQ1XrnOkQwupTig+SLxDx0PgDn3BM7duDtKgh6D+3HsUsrXF6O1StCt ZnhpS0mac1vhHF8LHY3uhsjqw5BCuFfxn65VLfRoGiegGl8aXqXHSYKIOOXuEgN9z8 NFIWsq1JBxoBxup228mV7Ti5LEM7ZzJioFl/ufayQkPWfRfMe/ypEIUIks40XN+Iti 3eVNaUXvCMxSOlUwMac2TmDDMo15q2UB5bGbbqD5y8cEvAUUNofOVMwYMGabEpTiy3 fZqlb3eiAbqNg== Date: Mon, 20 Feb 2023 12:40:54 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83zg98v7qs.fsf@gnu.org> Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> <83zg98v7qs.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> BTW, this makes me wonder why emacs_re_max_failures is not accessible >> from Elisp. I think it would be very useful, if only for debugging >> purposes. And perhaps let-binding it to a lower value around some >> potentially (or actually) problematic regexps would be a good way to >> prevent or fix bugs such as the current one. > > If we know which regexps cause problems, shouldn't we instead fix those > regexps, or change how we use them? > If we know how and where to fix them, that's better of course. If we don't (and frankly when I look at that regexp I have no idea how it could be fixed), limiting the backtracking depth to a more reasonable value is better than not fixing the bug. > > For debugging purposes, you can set the value in the debugger after > starting Emacs, or with a breakpoint just before calling the problematic > code. > That's only true for the (very) few of us who are comfortable building Emacs and running it under GDB (and even for them it's much easier to just change the value with a setq). If regexp-max-backtracking-depth had been present, everyone could easily have tried to set it to some lower value. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 07:41:18 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 12:41:18 +0000 Received: from localhost ([127.0.0.1]:50852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5Tq-0001PU-6A for submit@debbugs.gnu.org; Mon, 20 Feb 2023 07:41:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5To-0001PG-04 for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 07:41:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5Th-0006FL-Fi; Mon, 20 Feb 2023 07:41:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lVN/lIEXr3zUyOuPDdaN482X0RkmKfVlUuJDjznekEo=; b=MitCVUi2lAGC Cfg6XxEuno2nwcGUxRFp7ELZ70ZNCvtdogKHBxZuW4LDsjDlriOEf0j4aryzvGpJ651vLBQLjlaCW 5QixtQuM0QEEaeDuvQ8tst7TO2vLJMPrSQHPEwQTagC4VwqAN48iNDWHcxEUSEwWEOeCCinweBD5q wmz+Yvn0cmdFGMgggHV2m46J1gu81AukKDmtcYNemG1lbXyCfG/NcNljqFGUCQks7pbPsMHUAdA4c PaRwN+jL0/XsNNYRQrKu+ix+S/pXwbTPerfqhW+RnnWncmfS7h1NFQI3CpQ+UDJxbfMV+8/XqiJIs hA+Is925Zu5QeSypv7b/9Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5Tg-00068V-Pe; Mon, 20 Feb 2023 07:41:09 -0500 Date: Mon, 20 Feb 2023 14:41:17 +0200 Message-Id: <83v8jwv79u.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 61514@debbugs.gnu.org > Date: Sun, 19 Feb 2023 18:38:52 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > After this, Emacs appears to hang and nothing else is displayed. > > That's a second and separate bug (tho probably triggered by the first). > These tend to be nastier to diagnose. What happens here that causes the "hang" is clear: the problematic regexp is used in a looking-at call that is called via fontification-functions, so its being pathologically slow wedges redisplay. The backtrace is below: #2 0x0121ccc0 in re_match_2_internal (bufp=0x19c5a50 , string1=0x83207d0 ", "\">\n", size1=0, string2=0x83207d0 ", "\">\n", size2=250000, pos=10, regs=0x1870074 , stop=250000) at regex-emacs.c:4581 #3 0x0121b22e in rpl_re_match_2 (bufp=0x19c5a50 , string1=0x83207d0 ", "\">\n", size1=0, string2=0x83207d0 ", "\">\n", size2=250000, pos=10, regs=0x1870074 , stop=250000) at regex-emacs.c:3861 #4 0x01208bba in looking_at_1 (string=XIL(0x8000000007a39ed8), posix=false, modify_data=true) at search.c:314 #5 0x01208db4 in Flooking_at (regexp=XIL(0x8000000007a39ed8), inhibit_modify=XIL(0)) at search.c:350 #6 0x01279aad in funcall_subr (subr=0x187b8c0 , numargs=1, args=0x6c40448) at eval.c:3036 #7 0x012ec2be in exec_byte_code (fun=XIL(0xa000000006c10520), args_template=769, nargs=2, args=0x6c40458) at bytecode.c:809 #8 0x0127a046 in fetch_and_exec_byte_code (fun=XIL(0xa000000007ea04f8), args_template=257, nargs=1, args=0x6c401c8) at eval.c:3081 #9 0x0127a5a5 in funcall_lambda (fun=XIL(0xa000000007ea04f8), nargs=1, arg_vector=0x6c401c8) at eval.c:3153 #10 0x01279512 in funcall_general (fun=XIL(0xa000000007ea04f8), numargs=1, args=0x6c401c8) at eval.c:2945 #11 0x01279897 in Ffuncall (nargs=2, args=0x6c401c0) at eval.c:2995 #12 0x0127895a in run_hook_wrapped_funcall (nargs=2, args=0x6c401c0) at eval.c:2773 #13 0x01278e11 in run_hook_with_args (nargs=2, args=0x6c401c0, funcall=0x1278912 ) at eval.c:2854 #14 0x012789a9 in Frun_hook_wrapped (nargs=2, args=0x6c401c0) at eval.c:2788 #15 0x01279ef7 in funcall_subr (subr=0x187ff80 , numargs=2, args=0x6c401c0) at eval.c:3059 #16 0x012ec2be in exec_byte_code (fun=XIL(0xa00000000615096c), args_template=514, nargs=2, args=0x6c400f8) at bytecode.c:809 #17 0x0127a046 in fetch_and_exec_byte_code (fun=XIL(0xa00000000615043c), args_template=257, nargs=1, args=0x82ac08) at eval.c:3081 #18 0x0127a5a5 in funcall_lambda (fun=XIL(0xa00000000615043c), nargs=1, arg_vector=0x82ac08) at eval.c:3153 #19 0x01279512 in funcall_general (fun=XIL(0xa00000000615043c), numargs=1, args=0x82ac08) at eval.c:2945 #20 0x01279897 in Ffuncall (nargs=2, args=0x82ac00) at eval.c:2995 #21 0x0127394d in internal_condition_case_n (bfun=0x127974b , nargs=2, args=0x82ac00, handlers=XIL(0x30), hfun=0x10428ae ) at eval.c:1558 #22 0x01042ae1 in safe__call (inhibit_quit=false, nargs=2, func=XIL(0x477df6c), ap=0x82acc4 "") at xdisp.c:3024 #23 0x01042b5a in safe_call (nargs=2, func=XIL(0x477df6c)) at xdisp.c:3039 #24 0x01042bae in safe_call1 (fn=XIL(0x477df6c), arg=make_fixnum(1)) at xdisp.c:3050 #25 0x01046b6a in handle_fontified_prop (it=0x82af58) at xdisp.c:4445 #26 0x0104554e in handle_stop (it=0x82af58) at xdisp.c:3978 #27 0x01052103 in reseat (it=0x82af58, pos=..., force_p=true) at xdisp.c:7509 #28 0x010444d5 in init_iterator (it=0x82af58, w=0x7967568, charpos=1, bytepos=1, row=0x7adeaf0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:3488 #29 0x0104484d in start_display (it=0x82af58, w=0x7967568, pos=...) at xdisp.c:3595 #30 0x0107ccaa in try_window (window=XIL(0xa000000007967568), pos=..., flags=1) at xdisp.c:20568 #31 0x01079885 in redisplay_window (window=XIL(0xa000000007967568), just_this_one_p=false) at xdisp.c:19960 #32 0x01070924 in redisplay_window_0 (window=XIL(0xa000000007967568)) at xdisp.c:17446 #33 0x0127373a in internal_condition_case_1 ( bfun=0x10708cc , arg=XIL(0xa000000007967568), handlers=XIL(0xc00000000648471c), hfun=0x107058e ) at eval.c:1498 #34 0x01070550 in redisplay_windows (window=XIL(0xa000000007967568)) at xdisp.c:17416 #35 0x0106ed14 in redisplay_internal () at xdisp.c:16866 #36 0x0106c42e in redisplay () at xdisp.c:16049 #37 0x0117570b in read_char (commandflag=1, map=XIL(0xc000000007e4f0f0), prev_event=XIL(0), used_mouse_menu=0x82f41f, end_time=0x0) at keyboard.c:2627 #38 0x0118f671 in read_key_sequence (keybuf=0x82f6f8, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10074 #39 0x01170cf9 in command_loop_1 () at keyboard.c:1375 #40 0x01273650 in internal_condition_case (bfun=0x1170698 , handlers=XIL(0x90), hfun=0x116f666 ) at eval.c:1474 #41 0x01170105 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1124 #42 0x012724d7 in internal_catch (tag=XIL(0x10380), func=0x11700ce , arg=XIL(0x90)) at eval.c:1197 #43 0x01170070 in command_loop () at keyboard.c:1102 #44 0x0116f0c6 in recursive_edit_1 () at keyboard.c:711 #45 0x0116f364 in Frecursive_edit () at keyboard.c:794 #46 0x0116a10e in main (argc=2, argv=0xa428e0) at emacs.c:2529 Lisp Backtrace: "looking-at" (0x6c40448) "xmltok-scan-attributes" (0x6c403f0) "xmltok-scan-after-lt" (0x6c403b8) "xmltok-forward" (0x6c40388) "nxml-tokenize-forward" (0x6c40350) "nxml-extend-region" (0x6c40308) "font-lock-default-fontify-region" (0x6c40298) "font-lock-fontify-region" (0x6c40230) 0x7ea04f8 PVEC_COMPILED "run-hook-wrapped" (0x6c401c0) "jit-lock--run-functions" (0x6c400e8) "jit-lock-fontify-now" (0x6c40058) "jit-lock-function" (0x82ac08) "redisplay_internal (C function)" (0x0) From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 08:14:19 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 13:14:19 +0000 Received: from localhost ([127.0.0.1]:50960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5zn-0002N7-3H for submit@debbugs.gnu.org; Mon, 20 Feb 2023 08:14:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU5zk-0002Mt-Lm for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 08:14:17 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5zc-00061K-TT; Mon, 20 Feb 2023 08:14:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xowdDwSSDWWTkRVqSs2TFHeqrXDM2kSat5Gq/W0t5jc=; b=fwUybk22yex+ bTtmG52gxmQJdmhzo6w1f/fnV5DzsjEchTnFyvk89QVMZbhBDKI7+IfS+k0AGXcRf4YDrVt11EBgb b0fe12SpItZVLv/9GEGY4VcfYm9MVI9O7K+KT2BD8EUKXs1VseL8pjnrbgVQcpux9b+MKyYIEwNab /CkNF0BE7zpKMl8DjpnEiabbIkUqtLU3QTRkt1+9TBQNNeaoujt2xowHjYmikgLJRZIRbq37DK/Zm +2ki4MNGbAocBXP3OSfQ3pLqoQslCfbIk7Xh6oLnnTbOOBfK8lh9Sh74DtZ9Wn1mwnJzOHeIewGgW zU8Jbs2MvSvCgximp6WyRA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU5zY-0005nq-0F; Mon, 20 Feb 2023 08:14:08 -0500 Date: Mon, 20 Feb 2023 15:14:07 +0200 Message-Id: <83h6vgv5r4.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (message from Gregory Heytings on Mon, 20 Feb 2023 12:40:54 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> <83zg98v7qs.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 20 Feb 2023 12:40:54 +0000 > From: Gregory Heytings > cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca > > >> BTW, this makes me wonder why emacs_re_max_failures is not accessible > >> from Elisp. I think it would be very useful, if only for debugging > >> purposes. And perhaps let-binding it to a lower value around some > >> potentially (or actually) problematic regexps would be a good way to > >> prevent or fix bugs such as the current one. > > > > If we know which regexps cause problems, shouldn't we instead fix those > > regexps, or change how we use them? > > > > If we know how and where to fix them, that's better of course. If we > don't (and frankly when I look at that regexp I have no idea how it could > be fixed), limiting the backtracking depth to a more reasonable value is > better than not fixing the bug. So let's try fixing the issue that way first, and only fall back to "limiting failures" if we decide we failed with that. > > For debugging purposes, you can set the value in the debugger after > > starting Emacs, or with a breakpoint just before calling the problematic > > code. > > That's only true for the (very) few of us who are comfortable building > Emacs and running it under GDB (and even for them it's much easier to just > change the value with a setq). If regexp-max-backtracking-depth had been > present, everyone could easily have tried to set it to some lower value. I don't trust people who don't build Emacs and run it under GDB to use such a variable judiciously. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 08:19:41 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 13:19:42 +0000 Received: from localhost ([127.0.0.1]:50995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU64x-0002Wz-U5 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 08:19:41 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4151) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU64s-0002Wd-QS for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 08:19:38 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id ED49B4407F6; Mon, 20 Feb 2023 08:19:28 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 52B0C4407DE; Mon, 20 Feb 2023 08:19:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676899167; bh=E+HalXj5QUOPmAgAgG2NNTeRrDvddR2Pj24HVWSkxUQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Yj+e5TOoHddYU3Y1Zh00UwCrXrE86XsxTyYF4gZ2isLHfJqORE53JVMqjyQwlQlCg HUPDnGLlufLtdib6VNCVssYiPWUl8P8zhn7kq8DzjEA3uTwMizzir5ymwTaC9PYCLj AqMwswgiYIX/Xc4KKvlgD7KZuJ2v1wwM09WHoXcxYKpEELZJG9ui2I1+gfIeKM3pWv WNwFu0fOfBIoTKvb5tyjWwbyU21QksTfto9fYe3589oZBsOobIPuwu3kpi+SQxovxq 3JYUcxF6elP8q6ZjIfWciSCU8bZEF69fXZnZ67lQ/0SI4cT/mtpuyDcx6KXK6lJMRR hlW4VowUUk7uw== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 27E80123197; Mon, 20 Feb 2023 08:19:27 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <831qmkwmux.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 Feb 2023 14:19:18 +0200") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> Date: Mon, 20 Feb 2023 08:19:26 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.154 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> IIUC the above describes the code where we're stuck inf-looping inside >> `looking-at`? > Not inflooping, but very slowly backtracking, or so it seems. Duh, right. I meant "hang". Sorry for being a bit mushy-brained for a moment. >> Is it the same place where the regexp-stack overflow happens (and with >> the same regexp)? > > It's (almost) the same place, but not the same regexp. The regexp > which causes the stack-overflow message (which is emitted from > set-auto-mode, before entering redisplay) is this: > > "\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" > > As you can see, the prepended "[^<>\n]+?" in the regexp which "hangs" > makes all the difference. So the looking-at which fails reasonably > quickly is the first call to looking-at above, whereas the one the > "hangs" is the second one. Yes, it makes a lot of sense now. > Maybe this points out a way out of this misery? I think it does. E.g. there's a chance that using "[^<>\n]+?\\<" instead of "[^<>\n]+?" avoids the hang (not sure if it's the right thing to do for all the regexp that can be returned by `xmltok-attribute`, tho). And for the stack overflow I haven't yet found its origin. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 08:54:53 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 13:54:53 +0000 Received: from localhost ([127.0.0.1]:51044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6d3-0003Uh-5u for submit@debbugs.gnu.org; Mon, 20 Feb 2023 08:54:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6d0-0003UQ-9V for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 08:54:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU6cu-0006Xy-J1; Mon, 20 Feb 2023 08:54:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0/VaqimtGcsaX//DoMnXklJzpz7JXH5bGDIiG3gklqI=; b=RgQf9L9oUJ1Q kwUVBF2XWLZw0L4nWnHCvuahnr8jeOwxMoqB+JRg40195jU772sG/wGTqVMBeFSe/TrOJVeaKMVix KebbS1jr7aHjH6b89kVCwsAj/0i/QnxmTW1p6A1BnsdVXx/1Xav9BSgT9g34VawEjLc4Jg09tHe85 Wryy6isrxtzFWAS+J2VhI2tiwrKcipryyjm2z3boY6R9P1juEEaRDxLP+7YyKNoukFjm+Sm0nsRII jUtuf04eS5js4vbGGkf7o9teDw1txVxBsKdgDpy2vbQemyiFZ71BDYijDe+exneMpmtYCn2LBNaam iLl8OzrQ+p315V/TZfJLBA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU6cu-0005Eh-2z; Mon, 20 Feb 2023 08:54:44 -0500 Date: Mon, 20 Feb 2023 15:54:52 +0200 Message-Id: <83cz64v3v7.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 20 Feb 2023 08:19:26 -0500) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: mah@everybody.org, 61514@debbugs.gnu.org > Date: Mon, 20 Feb 2023 08:19:26 -0500 > > > "\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" > > > > As you can see, the prepended "[^<>\n]+?" in the regexp which "hangs" > > makes all the difference. So the looking-at which fails reasonably > > quickly is the first call to looking-at above, whereas the one the > > "hangs" is the second one. > > Yes, it makes a lot of sense now. > > > Maybe this points out a way out of this misery? > > I think it does. E.g. there's a chance that using "[^<>\n]+?\\<" > instead of "[^<>\n]+?" avoids the hang It does, thanks. > (not sure if it's the right thing to do for all the regexp that can > be returned by `xmltok-attribute`, tho). How would we go about finding out? Because other than that, changing the regexp solves this nasty problem, and all the tests in test/lisp/nxml/ still pass. > And for the stack overflow I haven't yet found its origin. Not sure what is the mystery here. AFAIU, we look for the closing ">", don't find it, and then start looking for fewer and fewer non-'>' characters followed by '>'. Isn't that what happens here? From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 09:06:17 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 14:06:17 +0000 Received: from localhost ([127.0.0.1]:51056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6o5-0003oK-AC for submit@debbugs.gnu.org; Mon, 20 Feb 2023 09:06:17 -0500 Received: from heytings.org ([95.142.160.155]:36978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6o1-0003oA-La for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 09:06:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676901972; bh=FvhcRnuixySRchrq0RouepN0WcwJrEJPVyQWn8KoRfo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=ihFYcl2DWvIyDekJPNOZnB46U+aabo3OucGmjWQPB3qhWsLl/J1AiP77duvmWJIE7 aAC1lVloFQ5yJs8cuuma1iIFWUOmmASdoQaTtRK44BWdZHzwV8Qt+1FJagErhtoPP3 zFq7S1PlltzCodASqFIzaUmT1owyCdjCv/s1q50wSgWjVh88Os55ugShP4oRAC/aI0 tRTGe7ce2EjZvevpF13QLKrye0YEi3ZE3czjmWHuQS3q4OFovGNveDfM8tkpzZA4Pl /fUT/NaznKTHxhcLZdrOvagoBQNbI37c+x5SLNn4BGeLv21WYrRW4M1c57N7v6QbQJ X7SZ5Fw8A4+bA== Date: Mon, 20 Feb 2023 14:06:12 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > I think it does. E.g. there's a chance that using "[^<>\n]+?\\<" > instead of "[^<>\n]+?" avoids the hang (not sure if it's the right thing > to do for all the regexp that can be returned by `xmltok-attribute`, > tho). > That does work, indeed. Using e.g. "[^<>\n]\\{1,100\\}?" also works (but is not as efficient). Perhaps Mark (who added xmltok.el to Emacs in 2007) can help here to determine what the right thing is? > > And for the stack overflow I haven't yet found its origin. > There is no stack overflow here, AFAIU. It's simply that the prepended regexp matches one or more (without any upper bound) characters except "<>\n", which means that we backtrack _a lot_ when the line is long. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 09:16:26 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 14:16:26 +0000 Received: from localhost ([127.0.0.1]:51103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6xu-0006VF-1X for submit@debbugs.gnu.org; Mon, 20 Feb 2023 09:16:26 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6xr-0006V0-JS for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 09:16:25 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3987E440870; Mon, 20 Feb 2023 09:16:18 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D154D440812; Mon, 20 Feb 2023 09:16:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676902576; bh=wcH5cdtUoajl2ai+JoRtjiz5LGRcqixTADrV1b76kFk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iENcYCves/i7vyLnvoNRrcPh/2Pjg52yRl2qWw96rd18RkANRgxLezWbeoTLoqpZl pQsC34JislpmiX8eUEtP4a5wh1MsZ3RY3CNKS0Kv7WNQuabT9GzIRZTBRqyP6GcWFN tc71veDfsaus85IcuTLMdBUt4uvmMNJ0FZWGk10vZFl2KHu3XLpKK9G5b7edeOgNJY goazQPuwSFo94ccfHzwpeh06O/RDkKyUULDc8zWwQlgrDFJg936pvOnWADolHUXFOr yHUhRSwy5oqX6B1eX5l48oju3C+TSVPA2AuMk7TvJxiHVKh+tk4OJB1OEj8tcznpxD HotzjSHEh0F4w== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A4F8012303A; Mon, 20 Feb 2023 09:16:16 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: (Gregory Heytings's message of "Mon, 20 Feb 2023 14:06:12 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> Date: Mon, 20 Feb 2023 09:16:15 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.147 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> And for the stack overflow I haven't yet found its origin. > There is no stack overflow here, AFAIU. It's simply that the prepended > regexp matches one or more (without any upper bound) characters except > "<>\n", which means that we backtrack _a lot_ when the line is long. There is clearly a stack overflow since the OP showed stack overflow errors in *Messages*. And the stack overflow is in the rest of the regexp: the `+?` repetition uses only ever 1 stack slot no matter how long a match we consider (contrary to the `+` and `*` repetitions which use N stack slots for the N repetitions of the longest match). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 09:17:29 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 14:17:29 +0000 Received: from localhost ([127.0.0.1]:51107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6yv-0006X1-Er for submit@debbugs.gnu.org; Mon, 20 Feb 2023 09:17:29 -0500 Received: from heytings.org ([95.142.160.155]:37020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU6yr-0006Wr-PS for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 09:17:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676902644; bh=SSmH4H3iYL/FTJTzeYgvjrDCZnd4dTUIi9t/vYYHmRI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=plrQNbrsyARMGeyVSDFUv9Bn7LERp10yCeiCQShS3Rqak8ZNpd/pAxBogkYpYZVZs StRIru0ty7DXRfYpkh2IrCLc62M26V1AdxcMqNsSyeor7S9aUpWWpKxQFtaSEmWzIT hZ0soJnMAHezWuuVp21le/UUCRRWjcJBkQAclViHTp/Oa8a/G2dc89JISgO08rCzNL 7vwUR6VY1QXHaHqxoEHeGTVtIrgdyS5FKdFg6InzDN7ZnYhUqbeLXYMwzDaevS2mS9 dbCCHywDJh6Rr6pQatSHUDyy76YX07kWAjaGgljHaWqvG0IPiG4X7UzjRWSN+jRuca qIJ30ZriE9/PQ== Date: Mon, 20 Feb 2023 14:17:24 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83h6vgv5r4.fsf@gnu.org> Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <886c06e50e9cfacb7954@heytings.org> <83h6vixik1.fsf@gnu.org> <886c06e50e707ab83560@heytings.org> <886c06e50e876183758c@heytings.org> <83zg98v7qs.fsf@gnu.org> <83h6vgv5r4.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> For debugging purposes, you can set the value in the debugger after >>> starting Emacs, or with a breakpoint just before calling the >>> problematic code. >> >> That's only true for the (very) few of us who are comfortable building >> Emacs and running it under GDB (and even for them it's much easier to >> just change the value with a setq). If regexp-max-backtracking-depth >> had been present, everyone could easily have tried to set it to some >> lower value. > > I don't trust people who don't build Emacs and run it under GDB to use > such a variable judiciously. > In the current patch it is automatically capped to a maximum value. It could also be automatically reset to a minimum value (say 1000 or 500 or 100). I just tried to set it to 500 in my configuration during a few minutes, and did not see any errors, so I don't see what could go fundamentally wrong if we give users control on that threshold. It would have been much easier to debug this bug by asking Mark "could you please try to temporarily set regexp-max-backtracking-depth to 1000 and see if that fixes the bug?". This bug report was easy to reproduce, so that wasn't necessary, but it would be for bug reports from users with more complex setup. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 09:24:14 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 14:24:14 +0000 Received: from localhost ([127.0.0.1]:51117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU75R-0006iL-R1 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 09:24:14 -0500 Received: from heytings.org ([95.142.160.155]:37044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU75P-0006iC-1T for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 09:24:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676903049; bh=S6TYZskJqfOb/Odat+X9GnaMWMyX6+dRwuPtaf9C+tI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=9g8UkDtQasZL8EWplpCQnKVVjWZCkwEs63IuqgG1LPRSAdsHvLHyiTNimAg9YwOfh nYX8ms9b7FQTHxQ8ELWTTfYgQtJx7MCoyS3Vns5ei/30gryxVqqQidCNnUbQc7v7Ft y6RIf6SJocWSmbHdQzQ9wKm1cMcKtfbV/AtldnfbadqTNu/5Z3/QjDrYIhlcPyBB+H 08qNihM2uDk+KDYa69xJ6kuCrOTrMn3kLSuSqBMh0kzzLLm/ET/tHi9O6uNbweqUVd UoVnKPJDWnh+Ns3WuNIxjHXU874rtWkE/BjxIpzXbfpvDCQKp/vx8LD49mCh59zI4D Mq+/VwT23WymA== Date: Mon, 20 Feb 2023 14:24:09 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> And for the stack overflow I haven't yet found its origin. >> >> There is no stack overflow here, AFAIU. It's simply that the prepended >> regexp matches one or more (without any upper bound) characters except >> "<>\n", which means that we backtrack _a lot_ when the line is long. > > There is clearly a stack overflow since the OP showed stack overflow > errors in *Messages*. > Ah yes, I misunderstood what you meant. I thought you were talking about a stack overflow bug in the regexp engine. > > And the stack overflow is in the rest of the regexp: the `+?` repetition > uses only ever 1 stack slot no matter how long a match we consider > (contrary to the `+` and `*` repetitions which use N stack slots for the > N repetitions of the longest match). > Indeed. That's the bug in the bug. But it's the '+?' repetition which causes the "infloop", right? From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 09:59:42 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 14:59:42 +0000 Received: from localhost ([127.0.0.1]:53254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU7dl-00089R-W4 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 09:59:42 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49633) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU7di-00089A-S6 for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 09:59:40 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 295F2807CB; Mon, 20 Feb 2023 09:59:33 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 878F380240; Mon, 20 Feb 2023 09:59:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676905171; bh=+kh96zdVs8rW65u6Nof4oTijzIVSJIeUWICtGyPomhA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bVOob67jeMgMNwB8IuM9HjTTnoQ7kahfqBGAiQjmFz7hhIGIboSKwjo4bFCbZOSLc 5yDwF7OqwxMoyLUFkoPGix6d7HkxXBDbZ+AoxK9OU/b5bXQfIVpsUaalQdpcKI5c5s GSy2ya0cFTE4Mbrnd8L6Pu5v1aYG9jcPzlmOs0quBRD19ThHnGAH9ROrduYJESWZPU B6wAEjgg7u0jqrLVzgBfBvigbR6Fs0oFtvZfJEcsZxXEZ4NX2O3TMDWbMnkECR6dqi cwzjhUrlzrhxee71piDxiUgFDET8UVYV5DpUi+YYW+XDZbx9SoXlfKqQAwRxglgdVh qNaiIAUN53OyQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6259D123197; Mon, 20 Feb 2023 09:59:31 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83cz64v3v7.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 Feb 2023 15:54:52 +0200") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> Date: Mon, 20 Feb 2023 09:59:30 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.122 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii [2023-02-20 15:54:52] wrote: >> From: Stefan Monnier >> Cc: mah@everybody.org, 61514@debbugs.gnu.org >> Date: Mon, 20 Feb 2023 08:19:26 -0500 >> >> > "\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" >> > >> > As you can see, the prepended "[^<>\n]+?" in the regexp which "hangs" >> > makes all the difference. So the looking-at which fails reasonably >> > quickly is the first call to looking-at above, whereas the one the >> > "hangs" is the second one. >> >> Yes, it makes a lot of sense now. >> >> > Maybe this points out a way out of this misery? >> >> I think it does. E.g. there's a chance that using "[^<>\n]+?\\<" >> instead of "[^<>\n]+?" avoids the hang > > It does, thanks. > >> (not sure if it's the right thing to do for all the regexp that can >> be returned by `xmltok-attribute`, tho). > > How would we go about finding out? Because other than that, changing > the regexp solves this nasty problem, and all the tests in > test/lisp/nxml/ still pass. I did find out: we'll always get the same regexp hre, so it's OK. It turns out that (xmltok-attribute regexp) doesn't mean to return "the something of `regexp`" but to return the "the regexp named `xmltok-attribute`". `xmltok-attribute` is a funny macro built by `xmltok-defregexp`. >> And for the stack overflow I haven't yet found its origin. > > Not sure what is the mystery here. AFAIU, we look for the closing > ">", don't find it, and then start looking for fewer and fewer non-'>' > characters followed by '>'. Isn't that what happens here? Right, but the stack overflows always come from repetitions where our `mutually_exclusive_p` test fails. Let's see: \\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*= The first two `*` should be non-backtracking because they repeat [-._[:alnum:]] which is mutually-exclusive with what follows (either `:` or whitespace, or `=`). Similarly the third `*` should be non-backtracking because its body can't match the `=` that must follow. \\(?:[\s\r\t\n]* there aren't enough whitespaces so even if this can backtrack it shouldn't be the source of our current problems. \\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?' Neither `*` here should backtrack. \\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\) Same here. \\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?" And here we're back to only repeating whitespace. What am I missing? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 10:02:49 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 15:02:50 +0000 Received: from localhost ([127.0.0.1]:53261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU7gn-0008Fa-M6 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 10:02:49 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU7gm-0008FO-LQ for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 10:02:49 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5880F44091D; Mon, 20 Feb 2023 10:02:43 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0BF2A4408BB; Mon, 20 Feb 2023 10:02:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676905362; bh=oNgbAHhzaqbzYhfUeQb8JoEFeEwsBSMzDaO8WSL99WM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=C94QNa78ZGrjwUW+bkYgHVm5V0HHUzVuK9dwLDHKdde9WnqBBQUxyHC7jaCz3QADO Ne09KHemI/fHAIUTSDyxpFosrWBUcVwbkCGTG+JXeBCDR/vwLRP5V9h8mZJo0HgCQ4 WJ7/Kfk1W1QCdP/QwRYrRpPZS7AByfXLrWXp2uFOHz8xHsyD+QTYn/45fo9uQz/BbZ FGjn7xL6sWOExApxJF+Iyxd79J6alUVrBRgLs+FWrOeel+mOFmNyu44nO+VUR0epeB yqo8kS4N7Lw10ntbLW5/RUM8LIDuDE3s4ZFu+cUO/BV8bjXXWDOys8cDY8dAW/WwM2 Ikv/lBFMGKn8g== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C72FD12303D; Mon, 20 Feb 2023 10:02:41 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: (Gregory Heytings's message of "Mon, 20 Feb 2023 14:24:09 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> Date: Mon, 20 Feb 2023 10:02:40 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.141 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Indeed. That's the bug in the bug. But it's the '+?' repetition which > causes the "infloop", right? It's the `+?` which causes the N repetitions of the O(N) time match, resulting in an O(N=B2) complexity, I think, yes. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 10:56:36 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 15:56:36 +0000 Received: from localhost ([127.0.0.1]:53305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU8Wq-0003bB-05 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 10:56:36 -0500 Received: from heytings.org ([95.142.160.155]:37160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU8Wm-0003av-4e for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 10:56:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676908590; bh=K0l/+hAmNtZthiGiEcWwMMfcEspxd8jMVQ4MSmFRWpw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=t5QgD7uyt09Q9Zk4LQAowUPcJGae0z76bSy3WQeceZkptGshumG3UmRXQPpDaStva 1dtZdbCRPLfTDmCNSY+ZXOYQAQK8qFk9Mp1pMKmOEIHD3NpxfiVY27tIvPP3OBQkhu xaC2Ewq4C8ZlhMPlSnxyRVWA6WK5SjrloMCc9QB+0KLtThrwtFQg+GYh/fLE4T0hvU lGsCVUFR7awvXp7V/9PTSAgPc9hfSomzDjgtVnnesJo3+PI+83aZGof7/k5SFTovYS xiX1jpwEycjal3ZXnAJts4Kqy+KeLSG5gIivRZ5n1iOh33itwrapsedks4e81MEVgG nXM8h4Wp71N1A== Date: Mon, 20 Feb 2023 15:56:30 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > What am I missing? > I don't know... but I observe that this alone: (with-current-buffer (get-buffer-create "*bug*") (insert "\n]+?\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?")) doesn't fail, so I don't think it's this regexp which causes the overflow. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 11:47:55 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 16:47:55 +0000 Received: from localhost ([127.0.0.1]:53344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU9KU-0004uY-Kz for submit@debbugs.gnu.org; Mon, 20 Feb 2023 11:47:55 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU9KR-0004tg-LJ for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 11:47:52 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 414C210011A; Mon, 20 Feb 2023 11:47:46 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6C5741000E6; Mon, 20 Feb 2023 11:47:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676911664; bh=qG7i3/3VcwNxUsoexOrRt3oiSMT3JmCEkI67KCO9Wxo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hw7jURvHX8sLHEXXFM0Ag7sTz2Wbm0qENCGtdKrFA3RLQrfw/AG1x2UVRkCp0didF RWNgmHzpPfG/CvyOtxGEfMjvV6T3xR6L/myKcAPflWb8rMojz91G+Cb5AvRaIc6IBk mAO+dw+/HHbhiIWrF8VrX7qZeFrXvoJwvCQ3DJUkWgAXA2gP5xKJTPPm9wCAzl+z5Z cykUYmrQUhYiwE3THebi52Kt6qPzlLqVrOB/aJ2QVYGmnkGtfAQwcfdnQHhhyV+Y3z 3W0djBAbiCwxUcx6UZantn0cQNpHIqZByLmRddCjUyr+KZ//6UeGXqjRrYy66Fyb53 QKjCzKluqzong== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 40B231231E5; Mon, 20 Feb 2023 11:47:44 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: (Gregory Heytings's message of "Mon, 20 Feb 2023 15:56:30 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> Date: Mon, 20 Feb 2023 11:47:38 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.141 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I don't know... but I observe that this alone: > > (with-current-buffer (get-buffer-create "*bug*") > (insert " (insert (make-string 250000 ?n)) > (goto-char 5) > (looking-at > "[^<>\n]+?\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?")) > > doesn't fail, so I don't think it's this regexp which causes the overflow. Indeed, there' still something unclear about how the overflow occurs, but at least it seems my analysis doesn't match emacs-regex.c's because I can get a stack overflow using the first part of the regexp: (with-current-buffer (get-buffer-create "*bug*") (erase-buffer) (insert " X-Spam-Score: -1.0 (-) > > I don't think it's this regexp which causes the overflow. > ... but with a larger buffer it does, so apparently the regexp is problematic after all: (with-current-buffer (get-buffer-create "*bug*") (let ((regexp "\\(\\(?:\\(xmlns\\)\\|[_[:alpha:]][-._[:alnum:]]*\\)\\(:[_[:alpha:]][-._[:alnum:]]*\\)?\\)[ \r\t\n]*=\\(?:[ \r\t\n]*\\('[^<'&\r\n\t]*\\([&\r\n\t][^<']*\\)?'\\|\"[^<\"&\r\n\t]*\\([&\r\n\t][^<\"]*\\)?\"\\)\\(?:\\([ \r\t\n]*>\\)\\|\\(?:\\([ \r\t\n]*/\\)\\(>\\)?\\)\\|\\([ \r\t\n]+\\)\\)\\)?")) (erase-buffer) (insert ") id 1pU9jz-0005iI-TB for submit@debbugs.gnu.org; Mon, 20 Feb 2023 12:14:16 -0500 Received: from heytings.org ([95.142.160.155]:37278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pU9jw-0005i6-RM for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 12:14:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676913251; bh=qINSAKqjF9PlWI3yJYW2hJvY8A9+uRm1/KbjP2H5mog=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=M3FNm9su0ieQ6t8eQCgOYjDUTEuj4nls23DJeYx7an/GMnwagq+VRC+Rq8vrLueJ0 XphS3d+eUpe8CPzyoR6CeT1GoIU37QDgItgfynAEgCQP/MFVwqf3AteQBTOR/iL6FA KI5cgqzugs9MCoNh9Y8YXDIFefnAIWDHYpf5jy/0nIkJWHdfA45xnAjhbVCFgGwPFy ZOGAzLNgvktYZPh9MCUoNh7A5AmKbdtiWriSRicJdTavx0ciLNy58qRUA6HdwIXzgF SPA4uv97SaDqUj6Bo5ohs80Q/Syt4FEG4GJea5fbnfMGytqGrgQ1vgh4XYuB0k0klL Rsn1sRI25IiIg== Date: Mon, 20 Feb 2023 17:14:11 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > where I can even reduce the regexp down to "[-._[:alnum:]]*\t*=". > > Looks like we're missing a case in our backtracking-elimination code. > Apparently we're doing the same thing at the same moment ;-) I simplified it down to: (with-current-buffer (get-buffer-create "*bug*") (erase-buffer) (insert (make-string 266666 ?n)) (goto-char (point-min)) (looking-at "[[:alpha:]]*=*")) This fails with 266666, and succeeds with 266665. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 12:34:52 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 17:34:52 +0000 Received: from localhost ([127.0.0.1]:53418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUA3w-0000E6-Dv for submit@debbugs.gnu.org; Mon, 20 Feb 2023 12:34:52 -0500 Received: from heytings.org ([95.142.160.155]:37308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUA3s-0000Du-D3 for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 12:34:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676914486; bh=iaIibjNiw6eJMQp90Nfqw6krrQ6yf5OOl3yf5nHj5Pw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=MM77hEuoNQLKmbfJRRUUgpjXhqHKu756LCBaCvHKGLQx22m0TfCpr1ddFIaIKzL5+ XcqdQpgb9fiXNC6a6V7yNzQjMPmzRFPukuCDRpIP4p4tfoLHbbgq2LwBVjNoQ2nf3s DQRLbwYrl38qTHMegLIKoMQx8MgQ0qMIKvVaV92rc2yk+IP5bqRkbpGjMpA8INmHmw 6XOFHqSCWJqNmPMq+TA5tqaC69LPCcfGB1UB5ym6QQdrCKJ1Upo7ICdXwSSWBhEjb7 xRsur/VCIwORihga3R65eQ+J61AhaJamzV1NijeC08LYFYJ6w9MNIfgbSXEjqP4/a7 SpRYB/zGDHsAg== Date: Mon, 20 Feb 2023 17:34:45 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > I simplified it down to: > > (with-current-buffer (get-buffer-create "*bug*") > (erase-buffer) > (insert (make-string 266666 ?n)) > (goto-char (point-min)) > (looking-at "[[:alpha:]]*=*")) > > This fails with 266666, and succeeds with 266665. > Even shorter: (with-current-buffer (get-buffer-create "*bug*") (erase-buffer) (insert (make-string 266666 ?x)) (goto-char (point-min)) (looking-at "x*=*")) Again this fails with 266666, and succeeds with 266665. Likewise: (with-current-buffer (get-buffer-create "*bug*") (erase-buffer) (insert (make-string 266666 ?x)) (insert "=") (goto-char (point-min)) (looking-at "x*=*")) fails with 266666 and succeeds with 266665. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 13:50:02 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 18:50:02 +0000 Received: from localhost ([127.0.0.1]:53518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBEg-0002IZ-60 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 13:50:02 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBEd-0002Hw-4f for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 13:50:01 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 74053806AA; Mon, 20 Feb 2023 13:49:53 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CC32180658; Mon, 20 Feb 2023 13:49:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676918991; bh=1t5Wv5Ywn3q7/4ZrEeU7DlipL7BHVwZGA2dEV+X4N4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ffV/56GU8txDSzYoK3sZI4CoDaRkMmlzC6jeF3BAQrwiCRSkMwI3AqIKrB7GSfLY9 b/fUPivHEA3UcgKvKrJa6cjCVQqfODlInuZIRCX8SoUJxMRe3Y0MJmalmYr5ik0jRh M7Ecn/dNKMv0Z1DZLmQUCWrmeGtyPl+lHEBpNIVny5Gt1D56scpwlxMZIzCuUN9+n6 lq8djUs0piGKMN/SceQrNQrIOwX8qs+7ZOnC4HnmjOW/uhWugLn2H23F3uqMJJTl47 dZFT0OSU6Z+f9Rx56VN4QEUTFRGfSf3/rhSMfXnNXlm5stAzkThb5niebey1cpGOU5 9HnNmv+/JMhnQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 959B012320F; Mon, 20 Feb 2023 13:49:51 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: (Stefan Monnier's message of "Mon, 20 Feb 2023 11:47:38 -0500") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> Date: Mon, 20 Feb 2023 13:49:49 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.110 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > where I can even reduce the regexp down to "[-._[:alnum:]]*\t*=". > Looks like we're missing a case in our backtracking-elimination code. The patch below fixes the stack overflow. [ And thanks Gregory for the yet simpler test cases. ] I don't think we want that for `emacs-29`, but unless there's some objection I'll push this to `master`, Stefan diff --git a/src/regex-emacs.c b/src/regex-emacs.c index 2dca0d16ad9..2571812cb39 100644 --- a/src/regex-emacs.c +++ b/src/regex-emacs.c @@ -3653,6 +3653,7 @@ mutually_exclusive_p (struct re_pattern_buffer *bufp, re_char *p1, re_opcode_t op2; bool multibyte = RE_MULTIBYTE_P (bufp); unsigned char *pend = bufp->buffer + bufp->used; + re_char *p2_orig = p2; eassert (p1 >= bufp->buffer && p1 < pend && p2 >= bufp->buffer && p2 <= pend); @@ -3822,6 +3823,23 @@ mutually_exclusive_p (struct re_pattern_buffer *bufp, re_char *p1, case notcategoryspec: return ((re_opcode_t) *p1 == categoryspec && p1[1] == p2[1]); + case on_failure_jump_nastyloop: + case on_failure_jump_smart: + case on_failure_jump_loop: + case on_failure_keep_string_jump: + case on_failure_jump: + { + int mcnt; + p2++; + EXTRACT_NUMBER_AND_INCR (mcnt, p2); + /* Don't just test `mcnt > 0` because non-greedy loops have + their test at the end with an unconditional jump at the start. */ + if (p2 + mcnt > p2_orig) /* Ensure forward progress. */ + return (mutually_exclusive_p (bufp, p1, p2) + && mutually_exclusive_p (bufp, p1, p2 + mcnt)); + break; + } + default: ; } diff --git a/test/src/regex-emacs-tests.el b/test/src/regex-emacs-tests.el index 34fa35e32ff..52d43775b8e 100644 --- a/test/src/regex-emacs-tests.el +++ b/test/src/regex-emacs-tests.el @@ -872,4 +872,15 @@ regexp-atomic-failure (should (equal (string-match "\\`\\(?:ab\\)*\\'" "a") nil)) (should (equal (string-match "\\`a\\{2\\}*\\'" "a") nil))) +(ert-deftest regexp-tests-backtrack-optimization () ;bug#61514 + ;; Make sure we don't use up the regexp stack needlessly. + (with-current-buffer (get-buffer-create "*bug*") + (erase-buffer) + (insert (make-string 1000000 ?x) "=") + (goto-char (point-min)) + (should (looking-at "x*=*")) + (should (looking-at "x*\\(=\\|:\\)")) + (should (looking-at "x*\\(=\\|:\\)*")) + (should (looking-at "x*=*?")))) + ;;; regex-emacs-tests.el ends here From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 14:11:36 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 19:11:36 +0000 Received: from localhost ([127.0.0.1]:53670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBZX-0002xH-SR for submit@debbugs.gnu.org; Mon, 20 Feb 2023 14:11:36 -0500 Received: from heytings.org ([95.142.160.155]:37410) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBZV-0002x8-QS for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 14:11:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676920292; bh=kwk21LumS7moeFkfOwRUWFptgi0D+z01ajINZnW6Hh4=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=pTfPPzeGc5RgNtCg3W/bxdEFqKhd4wuPRFXbjXZHkh8K8BwA4jQCvrdGo6axpgxIq d9kn4ts2y2n4l4IrCoGHgIhTKeZaIsbZvX0iZPcrtvTZugW3estnleKKQOS+apmSHT BO+DKcSdYfb9pt03s3G11LLP+weADtcq/TyZp76X+GyCsV1PJf46QDc9iwB/bxOtpi MzriA7zCoNXNw9lx/OLlKYcbhwuuEkB6s/MIAMPjYr9MIM+cs6/WJZ6ZTLODaoSqnb N4OCjyU7zU1BqJ4+HE9STtBy7HwC/dhYcZ0k/7QDl5+VLC+AkIXbG+lkaNl5+nTFAR 7c8TDhhGaWc6Q== Date: Mon, 20 Feb 2023 19:11:31 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > The patch below fixes the stack overflow. > Together with the "\\<" in xmltok.el, this fixes this bug indeed in all cases (truncated and non-truncated ones). Congrats! > > I don't think we want that for `emacs-29`, but unless there's some > objection I'll push this to `master`, > I'd say it fixes an important bug in the regexp engine, but I cannot judge whether it's important enough for emacs-29. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 14:29:34 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 19:29:34 +0000 Received: from localhost ([127.0.0.1]:53687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBqw-0003QP-67 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 14:29:34 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBqs-0003Q7-Kn for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 14:29:33 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1FB708051E; Mon, 20 Feb 2023 14:29:25 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 118EF8094B; Mon, 20 Feb 2023 14:29:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676921363; bh=WcXFSYNDeNEd6I+WCOUN/x2Kky8FpbDX6TexBvDp6ss=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JG1kF8VFKTnC8EM+AzK+WCsSCqhbwWyaOm93FxOjEuq7LbuxrtOXhLLocRW/8V5Qn lKr3XyE7EkD2mmerHN0G+Ny1xXANs4LDw2Dingjg9c22ycuODtMU44Jc1Kwzmn0s0E kw/byGtYuYGaZ/ePuPPKujASNgNYXG6im4IIhkMdbspXA2loBDGt+buYNUYxCrZifE sErnlMzjVQacBSgF7zAM8FjFMeqGIF59CBmEgDc1CqBNI8tGXIiAzwim9Ko7+PrdbP 2yH7XFZZRpc4LX4fXyngVqbbxJnlaHVE0rrMtqGGpSzF51JIeeTFRPo4UPI82FVvXI SHcBbBo5FRCXg== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B4C82122481; Mon, 20 Feb 2023 14:29:22 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: (Gregory Heytings's message of "Mon, 20 Feb 2023 19:11:31 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> Date: Mon, 20 Feb 2023 14:29:21 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.105 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I'd say it fixes an important bug in the regexp engine, but I cannot judge > whether it's important enough for emacs-29. FWIW, I've been using a slight variant of this code in my local Emacs hacks for the last probably 10-15 years (I can't remember when I wrote it, and the Git history only goes back to the Bzr->Git switch). I had completely forgotten about it, but while doing the tests, I saw that some cases were working better (in my local Emacs) than what I expected while reading the code on `master` :-) Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 14:38:04 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 19:38:04 +0000 Received: from localhost ([127.0.0.1]:53697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBzA-0003fB-H9 for submit@debbugs.gnu.org; Mon, 20 Feb 2023 14:38:04 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUBz6-0003ed-Mk for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 14:38:03 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 357994417F1; Mon, 20 Feb 2023 14:37:55 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B48484417F3; Mon, 20 Feb 2023 14:37:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676921873; bh=wkjJNLDSe8GHc7cJGkvvzIHV0g5ylIzsatH+xXGk4a8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VkvwnF9jrDc0o6kgtTuOhV36s03Lz+8SttoTrP/U9092mukhSIlfBX97bacVaXXLh e197bQp9EafUSx9oMMbNMGvHKJsikun7B+R957QCHm2mhUDsaBz8hQhWYVuC3FTTtM xxXVVmKY6d8iUDZPnk+HETUY8RS1ry15O2leDPy+wdDkeSnFyWGd4SKZSq9J11MPUL +/kFVS6H4jbuPFeIwJcwSmm5GgO/JH5JJmGuGKm5+O4ueMnTdrC3Q5YViOKni7pZ1D CTOM/++6bXmcbYJ1205ETa/s/bT/HgQRHEVEks7vG3/xDp/EA/JeCgRUCq3hcZE14L SI6WLJODpVN5A== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 79778123210; Mon, 20 Feb 2023 14:37:53 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: (Gregory Heytings's message of "Mon, 20 Feb 2023 19:11:31 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> Date: Mon, 20 Feb 2023 14:37:51 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.152 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> The patch below fixes the stack overflow. > Together with the "\\<" in xmltok.el, this fixes this bug indeed in all > cases (truncated and non-truncated ones). Congrats! We probably still have an O(N=B2) behavior which can bite with a line like My patch should significantly improve the constant factor, but with a long enough "N_N_N_N_N..." I suspect it can still end up painful. Maybe we should reduce the scope of the search for the fallback case (the case where we add the "[^...]+\\<" prefix) since AFAICT its only purpose is to try and guess a helpful error messages when the XML is ill-formed. >> I don't think we want that for `emacs-29`, but unless there's some >> objection I'll push this to `master`, > I'd say it fixes an important bug in the regexp engine, but I cannot judge > whether it's important enough for emacs-29. It's a missing optimization that's been with us for many many years, so I don't see any urgency to fix it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 15:01:28 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 20:01:28 +0000 Received: from localhost ([127.0.0.1]:53712 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUCLo-0004K7-FP for submit@debbugs.gnu.org; Mon, 20 Feb 2023 15:01:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUCLj-0004Jt-HB for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 15:01:26 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUCLd-0002ee-K5; Mon, 20 Feb 2023 15:01:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=C6jBqZ9RpDH9ycVvE30oAc3fpcSOqpY4ahncStWFCx4=; b=NvGdSXpEyaXG 3GEKwBTDOVkHpGwjjYuthd1sY+qe8JkAluFO3VXGHBcXQnS7RndZ9UJqhqK02PoWKmFMxv9pq+z9Y lgaOHgAwrjEacOpnCgPiujpCX6cJQJaatKET+wrqCTpYyDzyzV9ASDknPrGcvnsrHMk9jIYcSWYEi dwWOqUcne/SH1iuZMNc3dDJqHG9tHyGw/ZBwOjxTh4pqk2rb5iy+0PdWOxXDBCupr3LToaGH4bKy6 0aWZceUTtwd11OJ6sx5egA6PdGYP5yB6dnik1E3mhanvlYXYWNlcoS6sLh1KIo1yrqvbzn5qkomvQ y1jSEbspb/XCvqsg4627Rw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUCLb-0007MS-MN; Mon, 20 Feb 2023 15:01:17 -0500 Date: Mon, 20 Feb 2023 22:01:24 +0200 Message-Id: <83wn4ct8bv.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 20 Feb 2023 13:49:49 -0500) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: gregory@heytings.org, 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , mah@everybody.org, 61514@debbugs.gnu.org > Date: Mon, 20 Feb 2023 13:49:49 -0500 > > > where I can even reduce the regexp down to "[-._[:alnum:]]*\t*=". > > Looks like we're missing a case in our backtracking-elimination code. > > The patch below fixes the stack overflow. > [ And thanks Gregory for the yet simpler test cases. ] > > I don't think we want that for `emacs-29`, but unless there's some > objection I'll push this to `master`, Assuming all the regex-emacs-tests and search-tests pass after this change, please install on emacs-29, and thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 15:13:44 2023 Received: (at 61514) by debbugs.gnu.org; 20 Feb 2023 20:13:44 +0000 Received: from localhost ([127.0.0.1]:53726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUCXf-0004c0-Rj for submit@debbugs.gnu.org; Mon, 20 Feb 2023 15:13:44 -0500 Received: from heytings.org ([95.142.160.155]:37478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUCXd-0004bp-8H for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 15:13:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676924018; bh=6vT1Un2qtoXvnx7iCY2Zl680TYIrNU3sD0NvUmGwYbo=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=RZZq1BcLKaA063a3qycI83uAzg1LBNUYFuxoB/jPTqULuf+3F4Ry32uVs2uYOoFVK cAyfGDIArjHNF6tiHIOzvV1BKzAMGVWPq2JdvirR25/x5JQjxv6e5jKvRlJ5uIy2Ns +1n6FZ6MqjFZPSuW6R6MuBmzdj6eeVpjD4GVzZCbVhCkWwFL5TYw2t7qtBlFsmC7uL g9W6/AqU/sdZlIp1hl2+xPJZzv3iOaIJZSi5SLKuaWR68Ve2vve4Oxv28/zOp0qeTy Ac3Oj1bdzORj3iUzYTMXf0Q3hOV1QiWqfD5p8Sjhrt0gqDO6YzWjNX/aMc2AZ5gV2z dvqYN98Yqulfg== Date: Mon, 20 Feb 2023 20:13:38 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="aNKK0DwYBn" Content-ID: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --aNKK0DwYBn Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: > > We probably still have an O(N=C2=B2) behavior which can bite with a line = like > > > > My patch should significantly improve the constant factor, but with a=20 > long enough "N_N_N_N_N..." I suspect it can still end up painful. > I just tried that, with a 4 MB such line, and indeed the result is=20 painful, but nowhere as painful as this bug: opening that file takes=20 "only" about 4 minutes, after which it can be edited normally. > > Maybe we should reduce the scope of the search for the fallback case=20 > (the case where we add the "[^...]+\\<" prefix) since AFAICT its only=20 > purpose is to try and guess a helpful error messages when the XML is=20 > ill-formed. > That's an idea, yes. With the following patch even your "n_n_..." example= =20 opens almost instantanously: diff --git a/lisp/nxml/xmltok.el b/lisp/nxml/xmltok.el index c36d225c7c9..61783ea4dec 100644 --- a/lisp/nxml/xmltok.el +++ b/lisp/nxml/xmltok.el @@ -734,7 +734,7 @@ xmltok-scan-attributes (atts-needing-normalization nil)) (while (cond ((or (looking-at (xmltok-attribute regexp)) ;; use non-greedy group - (when (looking-at (concat "[^<>\n]+?" + (when (looking-at (concat "[^<>\n]\\{1,1000\\}?\\<" (xmltok-attribute regexp))= ) (unless recovering (xmltok-add-error "Malformed attribute" >>> I don't think we want that for `emacs-29`, but unless there's some=20 >>> objection I'll push this to `master`, >> >> I'd say it fixes an important bug in the regexp engine, but I cannot=20 >> judge whether it's important enough for emacs-29. > > It's a missing optimization that's been with us for many many years, so= =20 > I don't see any urgency to fix it. > It's not urgent, indeed. But it doesn't look risky either, especially=20 given that you've been using that patch for years. Anyway, I don't have a= =20 strong preference. --aNKK0DwYBn-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 20 21:23:45 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 02:23:45 +0000 Received: from localhost ([127.0.0.1]:54035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUIJl-0005oj-8N for submit@debbugs.gnu.org; Mon, 20 Feb 2023 21:23:45 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUIJh-0005oS-Vk for 61514@debbugs.gnu.org; Mon, 20 Feb 2023 21:23:44 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9393044304F; Mon, 20 Feb 2023 21:23:36 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 507CD44304C; Mon, 20 Feb 2023 21:23:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676946215; bh=rJ7YBNKvEfib8i5gZnoMpyRPQNM7VMpR3fPfSTxSiWA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Qb8QUW2nma8b8BXqZTITOD6f4XBAlJid8Lr0yWrlhfMgILRFE57j0sKGwhxoNvJQi pX3xOmfjVlJ5qlUD3b/c+yF+AjKqs6lt1/P9bIkDUnn6GND9r1T3vZF85hc1xxeBkA TqZe9wbZOJp5u89YLXrp6Ei/8UkMo0AthTf35fB9rOrjwabMopUqcv+IC2o0sK2Jyd 3sjU7B53n6ZHq6GRoWdeEGbJJOpQeFKTvgGwmlJRB48pdIL3ME/3gA6iYoJB3AZwbF f3bFF1hkEXeEiKaKxwrOpnhdZ1OS2OskLNfIT8dqKhKNStSkzuaiXfB0BIKXva6sCm kye8iABXYJbBQ== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 215771231A5; Mon, 20 Feb 2023 21:23:35 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83wn4ct8bv.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 Feb 2023 22:01:24 +0200") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83wn4ct8bv.fsf@gnu.org> Date: Mon, 20 Feb 2023 21:23:34 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.153 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: gregory@heytings.org, 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I don't think we want that for `emacs-29`, but unless there's some >> objection I'll push this to `master`, > > Assuming all the regex-emacs-tests and search-tests pass after this > change, please install on emacs-29, and thanks. It passed the tests, I pushed it to `emacs-29`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 04:39:27 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 09:39:27 +0000 Received: from localhost ([127.0.0.1]:54533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUP7O-0001dz-Ns for submit@debbugs.gnu.org; Tue, 21 Feb 2023 04:39:26 -0500 Received: from heytings.org ([95.142.160.155]:38176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUP7L-0001dn-0f for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 04:39:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676972361; bh=if6TEvMlwT8GCAwUTgipkq9RKFfhZSi+I2uA33Lox5w=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=RlRh/rQtgFiLizkCF+L2Mec0aDY/LyH7CG5REL4tUTtbsqJ1Lge8IOS/QMSE5dtBJ 5O6KCAY1IK2e/Ske6mP163Hugg7/7kGcpc7utMqD/kCR25LGSPkNeVChqOs2EZZuVG IvE+s8HQFXXrj8QSlG8Q4A+nZXQOM1wxpJRhJuqZnMJM/LzNxxrQ6h5zkBth6tiXLk Patsluw68r+xWz6xwNzWveOxHxj8F7Rhr8Xn9ljunFHVF6MoTecRr5gxsSKIKdLr80 v9eYF8YjEauGQY3rhwvRglwsxbNa6ByhWOcKtGmIPd2V8u52EBUqJ64cb8w7cTZ2LY SSj6P6zHBfowA== Date: Tue, 21 Feb 2023 09:39:21 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: <6abb5de68835461a4bd8@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83wn4ct8bv.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> I don't think we want that for `emacs-29`, but unless there's some >>> objection I'll push this to `master`, >> >> Assuming all the regex-emacs-tests and search-tests pass after this >> change, please install on emacs-29, and thanks. > > It passed the tests, I pushed it to `emacs-29`. > Great! I guess we should we also fix the bug in nXML? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 07:05:38 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 12:05:38 +0000 Received: from localhost ([127.0.0.1]:54793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUROs-0007B5-E9 for submit@debbugs.gnu.org; Tue, 21 Feb 2023 07:05:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUROq-0007AN-Ki for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 07:05:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUROl-0005dn-0O; Tue, 21 Feb 2023 07:05:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=l2BZXnCexAwTpyAgOMPlExPwZHjerxVeCyK6zIvTBJg=; b=M6tVkzpNAB0k XZfQemCzvQMVx0GTAhbuV+spikLalpOkvRcuL8/AbTwJTwAtPbiB0k3eYzqZEf9zV56vCEDsI6SVf 0m/2Sr4sh/n9kaUAMfgX1Fe1JIVkzWqeYVpJc6nqwGf66pUL9+K4hFnnmWvOC3TbQWZ11SkH/1miO CF/w8pv/XbfecP+lWWVmmXl8+UPenm/L51vCyVrVZQ75kzwz2aHmhUiTGvxY7EhgzdGBCykW76/K6 diMjKpAtOqIXEKe8gS1AVEfpzblsqYHgMDeXgVhoPmD95RY+kneFe30iskqqVycHbUndEdg1n+9ri hGQvikavUwUim52oBZrwPw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUROj-0000PG-NI; Tue, 21 Feb 2023 07:05:30 -0500 Date: Tue, 21 Feb 2023 14:05:40 +0200 Message-Id: <83r0ujte97.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (message from Gregory Heytings on Mon, 20 Feb 2023 20:13:38 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 20 Feb 2023 20:13:38 +0000 > From: Gregory Heytings > cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org > > > Maybe we should reduce the scope of the search for the fallback case > > (the case where we add the "[^...]+\\<" prefix) since AFAICT its only > > purpose is to try and guess a helpful error messages when the XML is > > ill-formed. > > > > That's an idea, yes. With the following patch even your "n_n_..." example > opens almost instantanously: > > diff --git a/lisp/nxml/xmltok.el b/lisp/nxml/xmltok.el > index c36d225c7c9..61783ea4dec 100644 > --- a/lisp/nxml/xmltok.el > +++ b/lisp/nxml/xmltok.el > @@ -734,7 +734,7 @@ xmltok-scan-attributes > (atts-needing-normalization nil)) > (while (cond ((or (looking-at (xmltok-attribute regexp)) > ;; use non-greedy group > - (when (looking-at (concat "[^<>\n]+?" > + (when (looking-at (concat "[^<>\n]\\{1,1000\\}?\\<" > (xmltok-attribute regexp))) SGTM, but isn't 1000 a somewhat low value? What if we use half of the value of long-line-optimizations-region-size instead? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 07:37:15 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 12:37:15 +0000 Received: from localhost ([127.0.0.1]:54851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pURtT-0002LC-Hj for submit@debbugs.gnu.org; Tue, 21 Feb 2023 07:37:15 -0500 Received: from heytings.org ([95.142.160.155]:38380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pURtR-0002Kx-4L for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 07:37:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676983031; bh=iMQy3qN6LuApUoqN8UGI/zSutr62ElsAwh082YESm2g=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=tWuiSz45gAiJGG2JE6PijqwyO/X83LegmwJykj1NjRp8/6GpO//zjR+nEbryD6anj s1XgdzBC+AIC9IuWgtWMLpHWqeUfWXCTA1Ec0gBIWijTLSZXiZEwW6AhKCo/s2oorm Edaq9tPYUs/ghawY5nhzKWJBeOH7HIPFqXVqr+SsGqdv0g9eoiOa4gSIGwGcG8xqK7 hGfJVFMgN2rlms75tD/CRgdHvuhYNHySK7JfrWbrrviTOkI9BrI4AQqLWPB423jdaD nxA//GfILq6LCL/7U79Xc7DeHzzrOh3rGY9KOXMhvuViFDRDl//cEaf3YUSO8dcxPo dy5wXu/9sxe/A== Date: Tue, 21 Feb 2023 12:37:11 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83r0ujte97.fsf@gnu.org> Message-ID: <6abb5de688808f8d363d@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > SGTM, but isn't 1000 a somewhat low value? What if we use half of the > value of long-line-optimizations-region-size instead? > Here are some benchmarks. The time taken by Emacs to open the 4 MB "n_n_..." file with different regexps are: "[^<>\n]\\{1,100\\}?\\<": 0.8 seconds "[^<>\n]\\{1,1000\\}?\\<": 3.4 seconds "[^<>\n]\\{1,10000\\}?\\<": 28.5 seconds "[^<>\n]\\{1,65535\\}?\\<": 162.9 seconds "[^<>\n]+?\\<": 356.6 seconds 65535 is the upper limit for such ranges, it's not possible to use a larger value. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 07:44:56 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 12:44:56 +0000 Received: from localhost ([127.0.0.1]:54860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUS0p-0002cb-PB for submit@debbugs.gnu.org; Tue, 21 Feb 2023 07:44:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUS0o-0002cN-EO for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 07:44:50 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUS0i-0006mt-Qo; Tue, 21 Feb 2023 07:44:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FvaSj/Gprvvt59iyswKssAdVn7HNCTiTPzZ4i8wzemA=; b=J7YDhFhGZnWm drNMsmeVubyuv5iy4DEbWMJCe/Obh0niuTVBs5Yb8CHSTuUbCp5uTWPDkymCfi/IVznexWYo7NN0l hMJqsOKNijXl5B8um3mTuOao7lTNni90ZhU13uIxU0E/n0EoYO4kpQVw+TG7dWW+nhS5bHp98P9gP oMqHNaNFCgAblPefPMB2MiAebvPduvxTKGcJ733HJw71iMjp9Pw5gCkiZtz7JR8m3A3HmUHKUd+Pm pd/uOnrOoalMp6aQNburhe61aAeG0kOmLRc7Tl0vxocbq7uVv7hqCyC3thLf8kEAWUFjBsKBVDiBV KOy+f2fIpkPpE6cMyA97vw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUS0e-0004EH-CH; Tue, 21 Feb 2023 07:44:44 -0500 Date: Tue, 21 Feb 2023 14:44:51 +0200 Message-Id: <83h6vftcfw.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <6abb5de68835461a4bd8@heytings.org> (message from Gregory Heytings on Tue, 21 Feb 2023 09:39:21 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83wn4ct8bv.fsf@gnu.org> <6abb5de68835461a4bd8@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 21 Feb 2023 09:39:21 +0000 > From: Gregory Heytings > cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org > > > >>> I don't think we want that for `emacs-29`, but unless there's some > >>> objection I'll push this to `master`, > >> > >> Assuming all the regex-emacs-tests and search-tests pass after this > >> change, please install on emacs-29, and thanks. > > > > It passed the tests, I pushed it to `emacs-29`. > > > > Great! I guess we should we also fix the bug in nXML? Yes, I'd like that to be fixed as well, but see my question about the hardcoded 1000. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 08:07:23 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 13:07:23 +0000 Received: from localhost ([127.0.0.1]:54916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUSMc-0003ci-O0 for submit@debbugs.gnu.org; Tue, 21 Feb 2023 08:07:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46152) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUSMb-0003cV-9d for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 08:07:21 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUSMV-0003Q3-5h; Tue, 21 Feb 2023 08:07:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sKC7rm6MrlzctF328FYMwbNZON2fP2QZ54EqyxDkeH8=; b=YqMuVaSbkfU/ EOi8qIqWikgH2IB+RHV7Ynjpi2umkYoh3BhLGUqYJ1zIaRzrANDLSnqX/go9Q6gCMgQSbPMim4PEe sr1Ep0PsQ6qZyKDQr1vFcZQiMv6e/Pagj8eiaEpyl+8+MpjsXYdaUQuGINxlfaO1FcpNyLHHG8ZJ/ bwb9fvEebw0OeLiyBlHRFF4jLThXxVNjbOo/3+6tAtfFGl1h8c3rKpxwB/3EQGmvTmgWIfKmyXzzg LzRjAHuGSbyYHEO7aXYowuGTfIhwVdDlMXYK8k4im7TaJi/9iJMnADk5Ij65sSxrdXdU5+8Dm3aDe 1AM2hVjFGHGgbR1lFM+a0w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUSMU-0007c8-6V; Tue, 21 Feb 2023 08:07:14 -0500 Date: Tue, 21 Feb 2023 15:07:24 +0200 Message-Id: <83bklntbeb.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <6abb5de688808f8d363d@heytings.org> (message from Gregory Heytings on Tue, 21 Feb 2023 12:37:11 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 21 Feb 2023 12:37:11 +0000 > From: Gregory Heytings > cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca > > > > > > SGTM, but isn't 1000 a somewhat low value? What if we use half of the > > value of long-line-optimizations-region-size instead? > > > > Here are some benchmarks. The time taken by Emacs to open the 4 MB > "n_n_..." file with different regexps are: > > "[^<>\n]\\{1,100\\}?\\<": 0.8 seconds > "[^<>\n]\\{1,1000\\}?\\<": 3.4 seconds > "[^<>\n]\\{1,10000\\}?\\<": 28.5 seconds > "[^<>\n]\\{1,65535\\}?\\<": 162.9 seconds > "[^<>\n]+?\\<": 356.6 seconds > > 65535 is the upper limit for such ranges, it's not possible to use a > larger value. OK, but does it sound outrageous to have more than 1K of non-newline characters in a row without any brackets? At the very least, maybe make the value be in some variable? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 08:24:26 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 13:24:26 +0000 Received: from localhost ([127.0.0.1]:54968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUSd8-0004C1-3O for submit@debbugs.gnu.org; Tue, 21 Feb 2023 08:24:26 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUSd5-0004Bo-PP for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 08:24:24 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E31D8807CB; Tue, 21 Feb 2023 08:24:17 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7715B80058; Tue, 21 Feb 2023 08:24:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676985856; bh=q+ZfJ59Xlx036mbhOvwokMUmdOMxSJf4Sn3wOXDOhcQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KB5vc8azS+4qH45tU/AY7oaMD4zw/fWwvE0+p5xR6RlrwBqgFR8c390TM1+k1ZYka G3PFpgkVGN1cQIAtrLFEZy83eysW3z9vgaPNWW2ZgLYOej3mT/KDtZ30Gz0whyTXnZ kx3riyWCRcT46OY9lgmvFoUDZ4zfdzv2ojUKBzq5OBTx4ihelBuoYWyTv6Pd/UzIN6 d4tTe9YTsgVcfI0Ce/6rey9b6LC5Eewr6rsRdrtLU+T8+FjWXzTOOjGYQqooMpTByf xOmgeRoVGpAvncILLMlrMPB4UKYa+pTHKa0c+ZFeKe6Y//8HVYRhDuDFvlhdMpi+px l6nVxPaYpOsow== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4A141123212; Tue, 21 Feb 2023 08:24:16 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <6abb5de688808f8d363d@heytings.org> (Gregory Heytings's message of "Tue, 21 Feb 2023 12:37:11 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> Date: Tue, 21 Feb 2023 08:24:14 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> SGTM, but isn't 1000 a somewhat low value? What if we use half of the >> value of long-line-optimizations-region-size instead? >> > > Here are some benchmarks. The time taken by Emacs to open the 4 MB > "n_n_..." file with different regexps are: > > "[^<>\n]\\{1,100\\}?\\<": 0.8 seconds > "[^<>\n]\\{1,1000\\}?\\<": 3.4 seconds > "[^<>\n]\\{1,10000\\}?\\<": 28.5 seconds > "[^<>\n]\\{1,65535\\}?\\<": 162.9 seconds > "[^<>\n]+?\\<": 356.6 seconds > > 65535 is the upper limit for such ranges, it's not possible to use > a larger value. BTW, personally when I suggested to limit the search I was thinking of `narrow-to-region` (which bounds both N factors in the N=B2 complexity). AFAIK this part of the code is intended mostly when editing XML by hand, where attributes aren't expected to be ridiculously long, so limiting to a few kB would be perfectly acceptable (and if the search fails it's not big deal: when the search succeeds we don't *really* know what it means either, it may be a false positive anyway). Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 08:35:48 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 13:35:48 +0000 Received: from localhost ([127.0.0.1]:55010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUSo8-0004oF-49 for submit@debbugs.gnu.org; Tue, 21 Feb 2023 08:35:48 -0500 Received: from heytings.org ([95.142.160.155]:38472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUSo4-0004nE-67 for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 08:35:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676986542; bh=PumUwz6/u78+HG83IUxIGAPT4Y8N2JnRzTk3laBFyJg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=2i8rg1xB+M7C8M92baUoKCZYfUZ3IUgZmnUrdRFVaKVAV0XURBrQKWs36XhTEijE1 FSz3r/TujTgqRVPGA1W0E8Fxnt7RmzRNZ9K/NVCF8smzmfBqSsZI3Lrnd97Fp6IHnb DH1TZUSIFWKiGpJj2Nh6d1JOErBgV9kIfeW3YOzgwMsmBSU8gBo4HXM1ArBIS9Y41X 5Uufzu1SRiPwdPzl5BKxZjQ93fUBvKiw9XjIpnLJTNhseJhNQYsVeWKKeutXQTQPjX UPZt2N+DvcshwWnYttUnhHlFoRvRSV/szoFnSNriuGjvLqnBzZ/rP62BwGf+uadpOF 46MErbR0LCBtg== Date: Tue, 21 Feb 2023 13:35:42 +0000 From: Gregory Heytings To: Stefan Monnier Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: <6abb5de688b2692446f9@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="glEOrdaMFc" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --glEOrdaMFc Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable > > BTW, personally when I suggested to limit the search I was thinking of=20 > `narrow-to-region` (which bounds both N factors in the N=C2=B2 complexity= ). > Indeed, that's another way to cope with that problem, and a better one: diff --git a/lisp/nxml/xmltok.el b/lisp/nxml/xmltok.el index c36d225c7c9..9badd7e4c53 100644 --- a/lisp/nxml/xmltok.el +++ b/lisp/nxml/xmltok.el @@ -734,8 +734,10 @@ xmltok-scan-attributes (atts-needing-normalization nil)) (while (cond ((or (looking-at (xmltok-attribute regexp)) ;; use non-greedy group - (when (looking-at (concat "[^<>\n]+?" - (xmltok-attribute regexp))) + (when (with-restriction + (point) (+ (point) 10000) + (looking-at (concat "[^<>\n]+?" + (xmltok-attribute regexp))= )) (unless recovering (xmltok-add-error "Malformed attribute" (point) With this opening the 4 MB file takes 1.6 seconds. With 5000 instead of=20 10000 it takes 0.8 seconds. > > AFAIK this part of the code is intended mostly when editing XML by hand,= =20 > where attributes aren't expected to be ridiculously long, so limiting to= =20 > a few kB would be perfectly acceptable (and if the search fails it's not= =20 > big deal: when the search succeeds we don't *really* know what it means= =20 > either, it may be a false positive anyway). > Indeed. --glEOrdaMFc-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 09:38:48 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 14:38:48 +0000 Received: from localhost ([127.0.0.1]:55144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUTn6-0001Jw-2k for submit@debbugs.gnu.org; Tue, 21 Feb 2023 09:38:48 -0500 Received: from heytings.org ([95.142.160.155]:38552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUTn1-0001Jk-Kb for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 09:38:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676990322; bh=YdF7IRRuKtdObxzYwbc/YY8pOLSh8YcGbfPPHT5GYGg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=NQMfpwRZIWCszKz76BJN7/660o9lqL5DaiHk4tpsN+2BTaGsA/kVWy8ekKnBkS4S3 f+J2yZiUz4IUvC7w2Eb7JwKcHWpBabbB2jGg4PY07UBLK2Er0Hn/nttjxRVrMUQlgA VnC1+BTOS/JR/QV8DdiWX29NPb1fmqjjAZmCitpRa3ze4uMS7kIOTO2f3ydfpaiCYD 0Rjf1BL1DWSXBvfuEdETu01NIat8ECmyxvvBsZI+YTNW6dm0rKcZlN+6c0GDc10sQf Q5nV41biWsu1xDm35hpBrfgTjb9ffE0/B0kn1spSWIk6klAd9Mn3eDeMcWwxZgm1V2 C7n3vPjhb4SgQ== Date: Tue, 21 Feb 2023 14:38:41 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83bklntbeb.fsf@gnu.org> Message-ID: <6abb5de688545b31428e@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > OK, but does it sound outrageous to have more than 1K of non-newline > characters in a row without any brackets? > > At the very least, maybe make the value be in some variable? > See my reply to Stefan. With a 'with-restriction' of 10000 chars, the file opens in 1.6 seconds. I'm not sure it would make sense to add a variable/defcustom there instead of the (admittedly somewhat arbitrary) constant 10000, which should be large enough in practice. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 09:48:52 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 14:48:52 +0000 Received: from localhost ([127.0.0.1]:55153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUTwq-0001dN-F5 for submit@debbugs.gnu.org; Tue, 21 Feb 2023 09:48:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUTwo-0001dB-Pw for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 09:48:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUTwi-00071g-JD; Tue, 21 Feb 2023 09:48:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=V7ImNMWhZjX/42J/FNk8FhwUDe1M6iPpeRBUIPGCk5I=; b=l8Zb53AM0o8s VOCm4/xCOXVn6p25em0YS3TR0eEFsa5qVt9xuEAF8a7HZGW4W8sievpcvgxmAMPWuju1ebwdK9ztS gKNOLJw68DuHg6FFbuzd5vFR43GnucH7omkfRQmbScC3ewS32gUT9vVzP1DAW+gSBk/PHUvI0p6tY Z2oOym/kmwbiNdAHzTLWPxI0/7mRZAxyCQIpjLpTnBiQBIc4UvRp7HOuGV0vsJ4u/IjkwqExOBo+6 I40YIdS2laRZhi3v4rqmDbGrc7cyAkje5wmSQYi1WN1/90H1v761wGS55KQpidgcmN9xL7cK5iBtC LI/SND/0MJugOe/HY0WP3A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUTwh-0001i4-T6; Tue, 21 Feb 2023 09:48:44 -0500 Date: Tue, 21 Feb 2023 16:48:52 +0200 Message-Id: <837cwbt6p7.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: <6abb5de688545b31428e@heytings.org> (message from Gregory Heytings on Tue, 21 Feb 2023 14:38:41 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> <6abb5de688545b31428e@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 21 Feb 2023 14:38:41 +0000 > From: Gregory Heytings > cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca > > > > > > OK, but does it sound outrageous to have more than 1K of non-newline > > characters in a row without any brackets? > > > > At the very least, maybe make the value be in some variable? > > > > See my reply to Stefan. With a 'with-restriction' of 10000 chars, the > file opens in 1.6 seconds. I'm not sure it would make sense to add a > variable/defcustom there instead of the (admittedly somewhat arbitrary) > constant 10000, which should be large enough in practice. OK, then let's go with that version. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 10:25:46 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 15:25:46 +0000 Received: from localhost ([127.0.0.1]:57058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUUWY-00032K-GY for submit@debbugs.gnu.org; Tue, 21 Feb 2023 10:25:46 -0500 Received: from heytings.org ([95.142.160.155]:38632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUUWW-00032B-GY for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 10:25:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676993143; bh=84X9OwltbjxQZifpT7Tre8/fbyE7ZkJmugT3qJLlV88=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=PXROo+BcCanRW4OIM+oXp1KZBW7b8Apoqc0if3EUzRAwHhfpj+P7hAMpYuAHuypeU BUzI+ircOfNwjsdcTaMUn5JjVO09DQibjzpTNWy4WtxX1hDeZTvceDsH1tiQn6eMop BsuZx/gY7DEXIsTEib4NcA6zhn3d1sLdJzFhyvlwRZpoFuqGsqWhBBsCAZ8OVqbn6G eBRsZtEgR0627Y3Lf1tVj6kipAEw2b8yfhzuODQo/eC8Z7KS6MXNKr9aswmFbSf3/C msEvLB2po5+dZi5rL+txgNQTkuAjrStftv5amhik2Cq7uv6mN3/LnB4bxGVu150TJ6 wkSZKs/jII0ng== Date: Tue, 21 Feb 2023 15:25:42 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <837cwbt6p7.fsf@gnu.org> Message-ID: <6abb5de688b004f6f267@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> <6abb5de688545b31428e@heytings.org> <837cwbt6p7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> See my reply to Stefan. With a 'with-restriction' of 10000 chars, the >> file opens in 1.6 seconds. I'm not sure it would make sense to add a >> variable/defcustom there instead of the (admittedly somewhat arbitrary) >> constant 10000, which should be large enough in practice. > > OK, then let's go with that version. > OK, thanks. Stefan, do you have any further comments/objections on that version? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 10:45:00 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 15:45:00 +0000 Received: from localhost ([127.0.0.1]:57082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUUpA-0005t4-DJ for submit@debbugs.gnu.org; Tue, 21 Feb 2023 10:45:00 -0500 Received: from heytings.org ([95.142.160.155]:38672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUUp8-0005sw-TO for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 10:44:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1676994297; bh=tjWfKEII0WnnRqOx17P3nlYghrqSYZkJgMHCE9lPEqI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=yvQf8M63c3BJU7DEzFywTecgHOsdp8k7fB6L7AMNpDpqKgYK95/ujS+mHqB8GOeXs i4cTmWG1rAQL809L7/oMFcwjnGGm/cSTH5JB8pzYwpv8ba9ah3JBq4RAUm/cKMRVEe ShYhvzElbgOZwEhhdXHwAQXaWVPH7+nPkjvNlv496vTnqwrgXW6W8qYsZZbEUeOGbd 4u3DaZw/BxvEMUDTMHulGf4bAB+QWOq75k9z24f9HdC2T6LVwE2mK0YoK5GMGP0oMR mc4aFIbpGo1n3q0K12sK5m3V5ILCEVckJypcG2Pp2Yj1r/K6Q0usG+DZVSMJWqOK5J X7CY2xKRRzpqg== Date: Tue, 21 Feb 2023 15:44:57 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <6abb5de688b004f6f267@heytings.org> Message-ID: <6abb5de6884bd36cb594@heytings.org> References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> <6abb5de688545b31428e@heytings.org> <837cwbt6p7.fsf@gnu.org> <6abb5de688b004f6f267@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> See my reply to Stefan. With a 'with-restriction' of 10000 chars, the >>> file opens in 1.6 seconds. I'm not sure it would make sense to add a >>> variable/defcustom there instead of the (admittedly somewhat >>> arbitrary) constant 10000, which should be large enough in practice. >> >> OK, then let's go with that version. > > OK, thanks. Stefan, do you have any further comments/objections on that > version? > By the way, I noted that a variant of the regexp still produces stack overflows: (with-current-buffer (get-buffer-create "*bug*") (erase-buffer) (insert (make-string 266665 ?x) "=") (goto-char (point-min)) (looking-at "[^y]*=*")) 266665 overflows, 266664 does not. Is that expected? From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 11:58:24 2023 Received: (at 61514) by debbugs.gnu.org; 21 Feb 2023 16:58:24 +0000 Received: from localhost ([127.0.0.1]:57170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUVyC-0007nm-7q for submit@debbugs.gnu.org; Tue, 21 Feb 2023 11:58:24 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62498) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUVy9-0007nZ-V8 for 61514@debbugs.gnu.org; Tue, 21 Feb 2023 11:58:23 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 709DB443071; Tue, 21 Feb 2023 11:58:16 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2585C44306D; Tue, 21 Feb 2023 11:58:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1676998695; bh=UHZIsrkoxVNX07lyrKK4G3rO9t3nmJF0jdi/8ubcxW8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=D5khOw2du5FVdTXbQyLK+8fTlIyWB5vBX7jdGQ6SsYNbwiYIraQRloj82JuUdYM1I fthD3nbsD9XctcJjdnkTaNZVeVo0WXGdZNSgFCt519gWosrjBfAevx4mnwWxzbRNuJ T9sB7SEoA5ZdNpo1Ma8oOQTDLI6nyfNJMFgR1djEfXxrpNDyUJJcL5Q+HPC3ogJrXZ P6TM7zz4Ugjdlk/me+L4cpE7hs08lYJWmBvOs3yc2dOo1T1J19GTiRlOZoRHcY17gR 0EjA7tzdynSHFMZ2F2d/x9VK1aR9R8CbVzSPuroKEJFH4jPfegxcHhKUVx/F3z8Fu1 IuBXtEFxSdtRQ== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C0A7212322C; Tue, 21 Feb 2023 11:58:14 -0500 (EST) From: Stefan Monnier To: Gregory Heytings Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <6abb5de6884bd36cb594@heytings.org> (Gregory Heytings's message of "Tue, 21 Feb 2023 15:44:57 +0000") Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> <6abb5de688545b31428e@heytings.org> <837cwbt6p7.fsf@gnu.org> <6abb5de688b004f6f267@heytings.org> <6abb5de6884bd36cb594@heytings.org> Date: Tue, 21 Feb 2023 11:58:02 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: Eli Zaretskii , 61514@debbugs.gnu.org, mah@everybody.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> OK, thanks. Stefan, do you have any further comments/objections on >> that version? LGTM. > By the way, I noted that a variant of the regexp still produces stack > overflows: > > (with-current-buffer (get-buffer-create "*bug*") > (erase-buffer) > (insert (make-string 266665 ?x) "=") > (goto-char (point-min)) > (looking-at "[^y]*=*")) > > 266665 overflows, 266664 does not. Is that expected? Yes, there's "nothing" we can do about it (short of a significant redesign of the engine): [^y] also matches = so at every iteration of the loop, both paths (perform one more iteration, or exit the loop) are valid, so we need to try them both, which we do via backtracking. We'd need a "Thompson NFA" or something along the same lines to avoid it. Of course, we could also just backtrack less deep by exploring the search space in a different order (e.g. the `*?` repetition does that), but if we want to still return the same end result, we'd then have to explore more of the search space (and after the fact, choose which match we should return) rather than stop at the first match. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 18 06:59:25 2023 Received: (at 61514-done) by debbugs.gnu.org; 18 Mar 2023 10:59:25 +0000 Received: from localhost ([127.0.0.1]:46370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdUHV-00038U-B2 for submit@debbugs.gnu.org; Sat, 18 Mar 2023 06:59:25 -0400 Received: from heytings.org ([95.142.160.155]:44462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdUHT-00038L-3N for 61514-done@debbugs.gnu.org; Sat, 18 Mar 2023 06:59:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1679137160; bh=iEmiaaXxlm/iumatueJnwDwEZLSIJMSzjSIcsM0bEoE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=7Q79pjmXmGnBFrRTi89bWEbatkUYvuSAu0+ZFqAKg+2zlMXe0TTc/q+ZCR7L5SmnT Soux459RsydFFJk75w/JXxVP5LrZYHrhroAv50u5Osy50lhZpYS51Fan2zuHyfBTvv OAtTFTerU37D1lqZSCb6Xxxsr0QAAWD8aiapV46xLBEysRhqG/R6I2kqeGeKSQEmkR hDzkX6p9Ygw3hykBF0EHYzqfe4dzp9SkJ1SQ5NcIXN6fWnAb+dLCvHolt0J3einwQU LuxKAgOHN1PZ0gT0DVywFYBAcbeeUezsZe5e+WrpPPklv2NASrUdymGRFzT3n/qSrM 57KON636lhYGw== Date: Sat, 18 Mar 2023 10:59:20 +0000 From: Gregory Heytings To: mah@everybody.org Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> <6abb5de688545b31428e@heytings.org> <837cwbt6p7.fsf@gnu.org> <6abb5de688b004f6f267@heytings.org> <6abb5de6884bd36cb594@heytings.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514-done Cc: Eli Zaretskii , 61514-done@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) The patch to xmltok.el has just been pushed to emacs-29 (0eddfa28eb), and I'm therefore closing this bug. Thanks again for your bug report, Mark. Now that the bugs in the regexp engine and in xmltok have been fixed, your file opens in a fraction of a second. I suggest you also try to open a similar 40 MB or 400 MB one-line file, to see how Emacs 29 handles files with long lines. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 18 07:10:08 2023 Received: (at 61514) by debbugs.gnu.org; 18 Mar 2023 11:10:08 +0000 Received: from localhost ([127.0.0.1]:46378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdURs-0003PI-G3 for submit@debbugs.gnu.org; Sat, 18 Mar 2023 07:10:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdURp-0003Oe-6A for 61514@debbugs.gnu.org; Sat, 18 Mar 2023 07:10:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pdURj-0007XW-MH; Sat, 18 Mar 2023 07:09:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=urQs8zXtOuMQEexKW9Bvf9WQ0n8Ji9JOGYkMonqJ1Tg=; b=ahQKPZkh/bBv sts+K8dxLpeTBpYdYEo80zGLdAgi+VBwKWb1bfScCNa/QjoD4Tz0vBpNMMZvLbr+1OJwpFeFHOhzy mvPxWPP2runyRCcrRo8HT5Ho+7IklqRsy09kaqNmVm74RtIHVTt4rEP7CBNCxhYk7LszhOJBwlBkL XqElotKU7ZyA4bkWVAdTmmh1+lEUutCT0k2hWobZ28eBq/2hwGvSIERIO08/izZwP71J9wHQOLdjp /MBSW88QCoeH0oMD93o57Dj20PbBiugcbBsD7MnaKXVfRx0ZF3nM4XBW//1/uj0TpkDR/mjlsd/0Z y4umU83/ZsooKjgcyB6d0A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pdURi-0002iB-KF; Sat, 18 Mar 2023 07:09:59 -0400 Date: Sat, 18 Mar 2023 13:10:01 +0200 Message-Id: <83pm96b9iu.fsf@gnu.org> From: Eli Zaretskii To: Gregory Heytings In-Reply-To: (message from Gregory Heytings on Sat, 18 Mar 2023 10:59:20 +0000) Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> <6abb5de688545b31428e@heytings.org> <837cwbt6p7.fsf@gnu.org> <6abb5de688b004f6f267@heytings.org> <6abb5de6884bd36cb594@heytings.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 18 Mar 2023 10:59:20 +0000 > From: Gregory Heytings > cc: Eli Zaretskii , 61514-done@debbugs.gnu.org, > Stefan Monnier > > > The patch to xmltok.el has just been pushed to emacs-29 (0eddfa28eb), and > I'm therefore closing this bug. Thanks, but shouldn't we limit the END argument of with-restriction to not exceed (point-max)? I see no protection from this anywhere in the subroutines called by with-restriction. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 18 11:06:50 2023 Received: (at 61514) by debbugs.gnu.org; 18 Mar 2023 15:06:50 +0000 Received: from localhost ([127.0.0.1]:48879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdY8w-0006cX-9L for submit@debbugs.gnu.org; Sat, 18 Mar 2023 11:06:50 -0400 Received: from heytings.org ([95.142.160.155]:44718) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdY8t-0006cM-HW for 61514@debbugs.gnu.org; Sat, 18 Mar 2023 11:06:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1679152006; bh=H1VhaNxXdw4XDdgyk6GxxV+IWbz4GNVyOswc+8s28wg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=soXLYtkk+WdBS5jHXTcaIrrTrCbogyy42Pxd6PUF8j3C6g8yLd4YQt4T/BdwXmA90 6hN46BWl2GpqYmrfwk/W9t3c5Bl6Q/S/Zze9P0mdWZnpOCpK/KDneZ95MyHszP2qPp G33eUMRrnIUamNUZoNG3bcMxERcSkpWFb/zGIsQFxsYD5B9xI8ZpLMA4Ku81V9hTwL vuQfoVlDjSbftwvamk9+DCojwhCQLVFnYNY4+3fipVg6rbcCj5fXWWQZ9Azt8MOIwG wftq4ENeceYOrhzLgESTaxx529ltAF+SpJ1bDk1UyLxVyJfL9merwCv8UXoK95SxGg yrAfyf4xc+W9A== Date: Sat, 18 Mar 2023 15:06:46 +0000 From: Gregory Heytings To: Eli Zaretskii Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs In-Reply-To: <83pm96b9iu.fsf@gnu.org> Message-ID: References: <87lel0c65v.fsf@everybody.org> <838rgvymcd.fsf@gnu.org> <831qmkwmux.fsf@gnu.org> <83cz64v3v7.fsf@gnu.org> <83r0ujte97.fsf@gnu.org> <6abb5de688808f8d363d@heytings.org> <83bklntbeb.fsf@gnu.org> <6abb5de688545b31428e@heytings.org> <837cwbt6p7.fsf@gnu.org> <6abb5de688b004f6f267@heytings.org> <6abb5de6884bd36cb594@heytings.org> <83pm96b9iu.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 61514 Cc: mah@everybody.org, 61514@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> The patch to xmltok.el has just been pushed to emacs-29 (0eddfa28eb), >> and I'm therefore closing this bug. > > Thanks, but shouldn't we limit the END argument of with-restriction to > not exceed (point-max)? I see no protection from this anywhere in the > subroutines called by with-restriction. > Good catch, thanks! Now fixed (11592bcfda). From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 18 22:39:55 2023 Received: (at 61514-done) by debbugs.gnu.org; 19 Mar 2023 02:39:55 +0000 Received: from localhost ([127.0.0.1]:49224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdixf-00084z-9a for submit@debbugs.gnu.org; Sat, 18 Mar 2023 22:39:55 -0400 Received: from spam1.m5hosting.com ([206.71.179.219]:35242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdixd-00084n-Hj for 61514-done@debbugs.gnu.org; Sat, 18 Mar 2023 22:39:54 -0400 Received: from mail.nichework.com ([108.161.151.107]) by spam1.m5hosting.com with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdixQ-0000BU-DZ; Sat, 18 Mar 2023 19:39:51 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPA id A5905C34D4; Sat, 18 Mar 2023 22:39:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=everybody.org; s=dkim; t=1679193577; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to; bh=nh+8lFd6TtvYL8aTSrGCSIWCtUYWk6jCxqY0EEIGlxA=; b=JhWt+ZF5OlewHkCfGFLsEcF9ei4M9k+zTj3i2Zz/C0NgkAjaEGEAvx0YSYmusSSSiekEfR 5a4BwuzltriFfX6DMm82v0HTeo5Jm6PqevXU/G8Xb4WPk/fuADvg5uTBVsdU0xFHEVwBRa U6m+4ALsl2Xed2TL7KnHSExs2RiyM+ez57TwNMSJbUIV9SwbDQAAxwIr4fX3I+j1WLlqh/ nrlORfctu0OOuKDrdeSgxdrPFyXgfWiUsd/txajWAAFJLsbao4LaygTZZUrUY5sJwAJ8a8 kGEmePCrKxgO/1A2WBip4F5u5J4mJixgb1GNj/Z+Xihus+E5vExSUt8i6lN39Q== From: "mah" In-Reply-To: Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-73-1679193566.159353-104------" Date: Sat, 18 Mar 2023 22:39:26 -0400 To: "Gregory Heytings" MIME-Version: 1.0 Message-ID: <49-64167600-d9-d7bc880@30844939> Subject: =?utf-8?q?Re=3A?==?utf-8?q?_bug#61514=3A?==?utf-8?q?_30=2E0=2E50=3B?= sadistically long xml line hangs emacs User-Agent: SOGoMail 5.8.0 X-Last-TLS-Session-Version: None X-Originating-IP: 108.161.151.107 X-SpamExperts-Domain: out.m5hosting.com X-SpamExperts-Username: 108.161.151.107 Authentication-Results: m5hosting.com; auth=pass smtp.auth=108.161.151.107@out.m5hosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zqMcJPfQhQHfHPR0RkRZ8YXK0rhK0HB7wGB6UxxWL/K1bq 6tTFOsV/JTYrnTsWuwFE6u4CyQIx/nGgrRLPL8OO5aQATNxgrKoNpTYGbX6fmQ8LNHOia8vxkkAj sb4eHUSAC0CDtTsK7u5ZmvCZ8TOOFhfjpbXj2sKNqqA48UZ8PrfgLSpDJEMwTgKguln1W71mJFia ikvVxgjp0/k+1t1ZqjX7HlbR20JWrC3DWMQHNTXBaA+VYFz81xdsQriXbFE8IuWU0jri8Y5iYBUO 6XqhyGvE6lKbt5IpBi9tQJCpqXBCK6Rs8kNktWJu4Ts1inkqNTPk0oN0zQyN/zObPf6Ld5KN662n uyIn1nOqS+eOmFFUMGmC4d3YvPVv44uYmodPm6RXK8jvbO7WhOery+BCgJ6gd7D+YKGodpNYwSEk DwMpPNPb+38ahrKeBJeEhs541APOGyRuqKbOun7vlQzhwfhpspQKRAIBFcUdSV85+QlcEqQwypXG o7SVlY932OXIa8TqUpu3kikGL21AkKmp/1deKsScii9XUOCJpGXi4TOvEyDfomfsvhQiIxmA4aKX aGxH327mBdvq1bJTgiD5rSOIPpeqwlm2NDGXIJ2x7FH7tJ08+jdIJ4khdNtZchoZjmQz4aZbEJu5 fzPix2fKfz1blqsiz350v9/zUXwC2KDsKVGkc4vbYkwwgv+qpeGSJWSq0q79vA0xG1hT+CPyub5P oBL0A4c4xavWeeymsxEVniihuDwEGDcmr6e3OPT2aRQRqOZaTyYZpLogdCuTiXwvzqhVfT37pG7G 6HUKce77Hm1K36AwGiBVrf6MOpK8VLgYYA9yFwM6P7tOag+Wmm7e0qNa73RHaUUx5PLCCOCaJlcx lwtjxJ+u+QVwzttM8jeeJSytG/Wf88r2kBubMTbhe2wm7JTIXL9P2cPU46HHjOxJRlB8GpU6X7hA 19sXVj7XJh9CAIHTfozSx7PymXv1sXEODkbaL4d0RrCdMjo78syhNBsUNS5nVa1bVAomgvQJsfA4 TZbAXJiM1OlT7qNnN5qDqHye393xedRLGA== X-Report-Abuse-To: spam@spam1.m5hosting.com X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61514-done Cc: Eli Zaretskii , 61514-done@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) ------=_=-_OpenGroupware_org_NGMime-73-1679193566.159353-104------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 409 I have a few processes running on my laptop so load is pretty high righ= t now.=C2=A0 This means the file does not load in a fraction of a secon= d on emacs29 for me right now. It does load fairly quickly, though.=C2=A0 And editing close to the end= of the file is pretty snappy.=C2=A0 Inserting characters closer to the= beginning is slower. But, yes, this bug is fixed. I'm very pleased :) =C2=A0 ------=_=-_OpenGroupware_org_NGMime-73-1679193566.159353-104------ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 467 I have a few processes running on my laptop so load is pretty hig= h right now.  This means the file does not load in a fraction of a= second on emacs29 for me right now.

It does load fairly qui= ckly, though.  And editing close to the end of the file is pretty = snappy.  Inserting characters closer to the beginning is slower.
But, yes, this bug is fixed.

I'm very pleased :)
  ------=_=-_OpenGroupware_org_NGMime-73-1679193566.159353-104-------- From unknown Tue Sep 09 18:39:25 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 16 Apr 2023 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator