From unknown Sun Jun 15 01:08:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#42701: 28.0.50; Duplicate Edebug instrumentation of lambda form in some cases Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Aug 2020 16:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 42701 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 42701@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.159647326125509 (code B ref -1); Mon, 03 Aug 2020 16:48:02 +0000 Received: (at submit) by debbugs.gnu.org; 3 Aug 2020 16:47:41 +0000 Received: from localhost ([127.0.0.1]:45937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k2dcj-0006dK-0g for submit@debbugs.gnu.org; Mon, 03 Aug 2020 12:47:41 -0400 Received: from lists.gnu.org ([209.51.188.17]:37090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k2dcf-0006dA-77 for submit@debbugs.gnu.org; Mon, 03 Aug 2020 12:47:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51750) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2dce-0000xB-VC for bug-gnu-emacs@gnu.org; Mon, 03 Aug 2020 12:47:36 -0400 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]:46703) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k2dcc-0007zs-Si for bug-gnu-emacs@gnu.org; Mon, 03 Aug 2020 12:47:36 -0400 Received: by mail-ej1-x633.google.com with SMTP id l4so39270225ejd.13 for ; Mon, 03 Aug 2020 09:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Z1wMpobKYDYKLlrri82P31Y/ANkQyczBM7CEKw7rlUY=; b=c6+cU4jUcT0gwUTPHJ7m1MzBgSJxFGHsERfYp18m+NrIpsIOHayYtTQEg/WDBsSv+n /aPtaGlDLmi84x1CKOQMb/97plq1/2UFzGTArFJii4i146+JS/vqxhx/O1vToYGO703b q+n1dTke5a5ghJjhqrEsovrv2EQZP7NFtb5uiXdkoDLxK+rmkxApK5htbZP2irCuiZI6 paGDrywLj4BFZV47rdu413/P72MzTTxQXkLOOcb6f9gc0MJIo4m0vDouU7Hi/sJW0vx8 +bsmCEhy1JBFSQjWcAlJ9J4I0JsHlnTMqaULnyIbSJyL6kU0lLNsO7i0e56xS7Avz5ak +Hqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Z1wMpobKYDYKLlrri82P31Y/ANkQyczBM7CEKw7rlUY=; b=sWcew9T9yM7xG/9HkF7IGAH4VOxJG1ZVc1FCKN59IL43tD6snnHo9EDZhhghngiTsU AoP8DN9euOZaU0PbLX0ac+ljy0r2uOSbjtdjqN7CinCkmZT0bIZdKk+ZAMz6Hd9OmWOX /9XPN5qfigjfnCRGa7wszZruOSrWZKrO4v4MPnrD1XBprD5jdtsg6P7MXnyi9oRSkQ85 RwGXDNWwKpZKyRxfwbGLno5hC7J3Ug1FFew2Btb4z0e6FcLjTNXbgZ0srRf/g86a3xRJ MW0miQ3TXpd6AJkJb+KZZjezGIMCruD0fxsGqHJHM4q/ujtbEbApfp+Sn0y+xbUaY6eq kL6Q== X-Gm-Message-State: AOAM530/PSgoAC+R97UDY2hdcZ6laI++NqJcNhIHvG4SS0RceAlrXlcI j1Jntdpj6MqZ7dfeHrDqeqIWb0/e X-Google-Smtp-Source: ABdhPJyTXkuf/Jl+bwxmK4ZS9hLVuYSEFdw9fkgLPs24mzc71uM06+IY3O8C0DbSnUW0Nod98Ebe0g== X-Received: by 2002:a17:906:1bb1:: with SMTP id r17mr17246775ejg.268.1596473250538; Mon, 03 Aug 2020 09:47:30 -0700 (PDT) Received: from phst1 (p57aafed5.dip0.t-ipconnect.de. [87.170.254.213]) by smtp.gmail.com with ESMTPSA id bt20sm16741043edb.62.2020.08.03.09.47.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2020 09:47:29 -0700 (PDT) From: Philipp Stephani Date: Mon, 03 Aug 2020 18:47:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::633; envelope-from=p.stephani2@gmail.com; helo=mail-ej1-x633.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.1 (/) 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.1 (--) Create a file /tmp/edebug.el: $ cat /tmp/edebug.el=20 (defun f () (if-let (x (funcall (lambda (y) 1) 2)) 3 4)) Visit the file: $ emacs -Q -l subr-x -l edebug /tmp/edebug.el Now instrument the function `f' using C-u C-M-x. The *Messages* buffer will now contain Edebug: edebug-anon0 [2 times] Edebug: f The [2 times] indicates the problem: Edebug has instrumented two definitions with the same (generated) symbol. This is a problem when using Edebug for e.g. coverage instrumentation, as the coverage information is attached to the symbol itself (as a symbol property), and duplicate symbols when instrumenting code lead to subtle errors such as mismatching vector lengths for the position of the breakpoints and the hit counts. I'd speculate that this issue is similar to Bug#41988 in that Edebug defines instrumented symbols even when backtracking later. In this case, Edebug backtracks to the legacy (SYM VAL) form, but has already partially matched the ((SYM VAL)) form, including instrumenting the lambda form therein. I guess Edebug should perform some kind of two-phase instrumentation and instrument subforms only when a form has been chosen after backtracking. Since this is somewhat difficult to implement without rewriting larger parts of Edebug, it might be more feasible to regenerate anonymous symbols after a failed match. In GNU Emacs 28.0.50 (build 72, x86_64-pc-linux-gnu, GTK+ Version 3.24.18, = cairo version 1.16.0) of 2020-08-03 Repository revision: 16b7f413a9ff819c374e07ee927c1fd2b4138109 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12008000 System Description: Debian GNU/Linux rodete Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --enable-gcc-warnings=3Dwarn-only --enable-gtk-deprecation-warnings --without-pop --with-mailutils --enable-checking=3Dall --enable-check-lisp-object-type --with-modules 'CFLAGS=3D-O1 -ggdb3 -fno-omit-frame-pointer -fsanitize=3Daddress -fsanitize=3Dundefined -fsanitize=3Dpointer-compare -fsanitize=3Dpointer-subtract'' Configured features: XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY LIBSELINUX GNUTLS FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER Important settings: value of $LANG: en_US.utf8 value of $XMODIFIERS: @im=3Dibus locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822 mml easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton derived edmacro kmacro pcase ffap thingatpt url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars mailcap subr-x rx gnutls puny seq byte-opt gv bytecomp byte-compile cconv dbus xml compile comint ansi-color ring cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 68791 8062) (symbols 48 8629 1) (strings 32 23741 1958) (string-bytes 1 764239) (vectors 16 13112) (vector-slots 8 166367 5382) (floats 8 25 30) (intervals 56 221 0) (buffers 992 11)) --=20 Google Germany GmbH Erika-Mann-Stra=C3=9Fe 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erhal= ten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, l=C3=B6sche= n Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie mich bitte wissen, dass d= ie E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don=E2=80=99t forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. From unknown Sun Jun 15 01:08:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#42701: 28.0.50; Duplicate Edebug instrumentation of lambda form in some cases References: Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Aug 2020 20:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42701 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: acm@muc.de, 42701@debbugs.gnu.org Received: via spool by 42701-submit@debbugs.gnu.org id=B42701.159657198717790 (code B ref 42701); Tue, 04 Aug 2020 20:14:02 +0000 Received: (at 42701) by debbugs.gnu.org; 4 Aug 2020 20:13:07 +0000 Received: from localhost ([127.0.0.1]:49229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k33J5-0004cr-7A for submit@debbugs.gnu.org; Tue, 04 Aug 2020 16:13:07 -0400 Received: from colin.muc.de ([193.149.48.1]:14959 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1k33J3-0004cN-2t for 42701@debbugs.gnu.org; Tue, 04 Aug 2020 16:13:06 -0400 Received: (qmail 73146 invoked by uid 3782); 4 Aug 2020 20:12:58 -0000 Date: 4 Aug 2020 20:12:58 -0000 Message-ID: <20200804201258.73145.qmail@mail.muc.de> From: Alan Mackenzie Organization: muc.de e.V. In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.4.4-20191224 ("Millburn") (FreeBSD/11.3-RELEASE-p9 (amd64)) X-Spam-Score: 0.0 (/) 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 (-) Hello, Philipp. In article you wrote: > Create a file /tmp/edebug.el: > $ cat /tmp/edebug.el > (defun f () (if-let (x (funcall (lambda (y) 1) 2)) 3 4)) > Visit the file: > $ emacs -Q -l subr-x -l edebug /tmp/edebug.el > Now instrument the function `f' using C-u C-M-x. The *Messages* buffer > will now contain > Edebug: edebug-anon0 [2 times] > Edebug: f > The [2 times] indicates the problem: Edebug has instrumented two > definitions with the same (generated) symbol. I don't think you're correct, here. I think it's instrumented the lambda form twice, once for each arm of the edebug spec. It discards the first attempt, then succeeds at the second. The pertinent edebug spec (from the if-let definition in subr-x.el) looks like: ([&or (&rest [&or symbolp (symbolp form) (form)]) (symbolp form)] form body) . In the outer &or sub-spec, the (&rest ....) bit doesn't match, but the failure to match only happens after the "Edebug: edebug-anon0" message has been output the first time. Edebug then tries the (symbolp form) alternative, which does match and outputs the "...-anon0" message a second time. > This is a problem when using Edebug for e.g. coverage instrumentation, > as the coverage information is attached to the symbol itself (as a > symbol property), and duplicate symbols when instrumenting code lead > to subtle errors such as mismatching vector lengths for the position > of the breakpoints and the hit counts. I don't think this is happening (see above), but I admit not having looked into it all that closely. Do you have any further evidence of two distinct functions being mapped onto the same generated symbol? > I'd speculate that this issue is similar to Bug#41988 in that Edebug > defines instrumented symbols even when backtracking later. In this > case, Edebug backtracks to the legacy (SYM VAL) form, but has already > partially matched the ((SYM VAL)) form, including instrumenting the > lambda form therein. I guess Edebug should perform some kind of > two-phase instrumentation and instrument subforms only when a form has > been chosen after backtracking. Since this is somewhat difficult to > implement without rewriting larger parts of Edebug, it might be more > feasible to regenerate anonymous symbols after a failed match. I don't know why Edebug re-uses the symbol. But beyond the misleading double message in *Messages*, is there any harm done? Would it be less confusing if two distinct messages "Edebug: edebug-anon0" and "Edebug: edebug-anon1" were to be output? > In GNU Emacs 28.0.50 (build 72, x86_64-pc-linux-gnu, GTK+ Version 3.24.18, cairo version 1.16.0) > of 2020-08-03 > Repository revision: 16b7f413a9ff819c374e07ee927c1fd2b4138109 > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12008000 > System Description: Debian GNU/Linux rodete [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 15 01:08:40 2025 X-Loop: help-debbugs@gnu.org Subject: bug#42701: 28.0.50; Duplicate Edebug instrumentation of lambda form in some cases Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Aug 2020 15:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42701 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 42701@debbugs.gnu.org Received: via spool by 42701-submit@debbugs.gnu.org id=B42701.159698521927627 (code B ref 42701); Sun, 09 Aug 2020 15:01:01 +0000 Received: (at 42701) by debbugs.gnu.org; 9 Aug 2020 15:00:19 +0000 Received: from localhost ([127.0.0.1]:33266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4mo6-0007BW-PW for submit@debbugs.gnu.org; Sun, 09 Aug 2020 11:00:19 -0400 Received: from mail-ot1-f47.google.com ([209.85.210.47]:43795) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4mo2-0007BD-TD for 42701@debbugs.gnu.org; Sun, 09 Aug 2020 11:00:16 -0400 Received: by mail-ot1-f47.google.com with SMTP id r21so5324197ota.10 for <42701@debbugs.gnu.org>; Sun, 09 Aug 2020 08:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hyzlnIEe8QYAexZnLI8y5Xwc7OJ4BSWLC7is8J1waM4=; b=A4UzECvhotbXLVHGisVYXmqquNcwdyG4ewkoFzg4z+3U5rZk6HjlBlDRjuIHWNuWUc KUeLasLeGuHL8ZvcikeZIZMaEOeFy94UBLOBOTSZwnxudW7Xm+b/mabvAIJ+JVkyXgPP misqNCPgDVTFuK7be8jWX1oI4RgOxX2XOz/qgpERwEshp86GU38LbI3IUVk/fb8m6BtV nU0MpCdgZuPiDE3XnnXTLxOPW2t1T/1D/3FIl3kEjjCs4UG0Ta9+i88J4OT1/P0dOB23 LL43as5b5YI/8KtqvEKzYMadXtGVhu3zpPk1AimZ13TvLfK5ep2zwFBqAkTxHAVQFXbC sUzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hyzlnIEe8QYAexZnLI8y5Xwc7OJ4BSWLC7is8J1waM4=; b=CJvXyCQbKJ710Ra+qFDul+MDeJbqeFVF1+D6IXrbN76zEybLnSJCsttad5pKDQPLMT cxHsAw5jUEcqqR6O2lAZb4FTqVZd+Ag0WiqQpZLjVdG/lgDlzVTnbHEBYbe+QIUiVpbV dfz3Oo/c2oChOkF0GbJwjmzI/FTbWdeNcpH/Cj51QGfRjyPs+sBGnnUzZRZFirwSwh2w S0yG26s5f7KglCLSdtCFR+fbKTSs6HWY+WMYBwoG4FXN/qKrep2BudQt4RZOUc+SqQDg G+UJMIiqsxUa7uTLQgfTvrSP9Cx3jUTV86lJaCNKupsk3LLrAT4EAFF343MMwCBNSwMn oZPg== X-Gm-Message-State: AOAM532bnS0E4nrY2dSnVIkTYFHAiY3oeBazi/QU/D49odCTDpowI1aC 60Hwn0Pxr9GIl+MWPwQVNEKWennzu+Bg97q/by43UjUc X-Google-Smtp-Source: ABdhPJyRWjuS+dmYAt/fM5xR0hQjfT1d6gZkTrcjqNAQ0np8btaUlV+Wkyk92BXpNbT9gt3E3/sM6kz5/RhzEx+s31c= X-Received: by 2002:a9d:170c:: with SMTP id i12mr19758329ota.36.1596985208859; Sun, 09 Aug 2020 08:00:08 -0700 (PDT) MIME-Version: 1.0 References: <20200804201258.73145.qmail@mail.muc.de> In-Reply-To: <20200804201258.73145.qmail@mail.muc.de> From: Philipp Stephani Date: Sun, 9 Aug 2020 16:59:57 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) 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: -0.7 (/) ) Am Di., 4. Aug. 2020 um 22:12 Uhr schrieb Alan Mackenzie : > > Hello, Philipp. > > In article you wrote: > > > Create a file /tmp/edebug.el: > > > $ cat /tmp/edebug.el > > (defun f () (if-let (x (funcall (lambda (y) 1) 2)) 3 4)) > > > Visit the file: > > > $ emacs -Q -l subr-x -l edebug /tmp/edebug.el > > > Now instrument the function `f' using C-u C-M-x. The *Messages* buffer > > will now contain > > > Edebug: edebug-anon0 [2 times] > > Edebug: f > > > The [2 times] indicates the problem: Edebug has instrumented two > > definitions with the same (generated) symbol. > > I don't think you're correct, here. I think it's instrumented the > lambda form twice, once for each arm of the edebug spec. It discards > the first attempt, then succeeds at the second. > > The pertinent edebug spec (from the if-let definition in subr-x.el) > looks like: > > ([&or (&rest [&or symbolp (symbolp form) (form)]) > (symbolp form)] > form body) > > . In the outer &or sub-spec, the (&rest ....) bit doesn't match, but > the failure to match only happens after the "Edebug: edebug-anon0" > message has been output the first time. Edebug then tries the (symbolp > form) alternative, which does match and outputs the "...-anon0" message > a second time. That is correct, but when the match fails, it's already too late: Edebug (in `edebug-make-form-wrapper') has already performed some global mutations such as modifying `edebug-form-data' of the `edebug' property of the newly-generated symbol. These mutations aren't unwound after the first failed match. > > > This is a problem when using Edebug for e.g. coverage instrumentation, > > as the coverage information is attached to the symbol itself (as a > > symbol property), and duplicate symbols when instrumenting code lead > > to subtle errors such as mismatching vector lengths for the position > > of the breakpoints and the hit counts. > > I don't think this is happening (see above), but I admit not having > looked into it all that closely. Do you have any further evidence of > two distinct functions being mapped onto the same generated symbol? I've tried to provide some context in https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-08/msg00574.html. The most common symptom of such duplicate definitions (as defined by "calling `edebug-make-form-wrapper' twice with the same `edebug-def-name'") is https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853. > > > I'd speculate that this issue is similar to Bug#41988 in that Edebug > > defines instrumented symbols even when backtracking later. In this > > case, Edebug backtracks to the legacy (SYM VAL) form, but has already > > partially matched the ((SYM VAL)) form, including instrumenting the > > lambda form therein. I guess Edebug should perform some kind of > > two-phase instrumentation and instrument subforms only when a form has > > been chosen after backtracking. Since this is somewhat difficult to > > implement without rewriting larger parts of Edebug, it might be more > > feasible to regenerate anonymous symbols after a failed match. > > I don't know why Edebug re-uses the symbol. . My guess is that `edebug-old-def-name' becomes non-nil because the form has already been instrumented (https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=1a845a672dc73c8e98e6cb9bb734616e168e60ba#n1382). It's then reused in https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/edebug.el?id=1a845a672dc73c8e98e6cb9bb734616e168e60ba#n1250. > But beyond the misleading > double message in *Messages*, is there any harm done? Would it be less > confusing if two distinct messages "Edebug: edebug-anon0" and "Edebug: > edebug-anon1" were to be output? The duplicate message is just a symptom of calling `edebug-make-form-wrapper' twice with the same `edebug-def-name' symbol, and attaching various instrumentation data to the symbol. Depending on whether the two definitions are compatible, this can be harmless or lead to subtle issues like https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853. Therefore in my coverage instrumentation driver I'm rejecting such duplicate instrumentations (https://github.com/phst/rules_elisp/commit/31d30e99c21027c5859782229aebb314ed3cb36c, since it doesn't seem to be possible to predict whether the redefinition would indeed be harmless or trigger https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41853.