From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.devel Subject: Re: The poor quality of Emacs's backtraces Date: Thu, 13 Jul 2023 16:17:05 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11898"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 13 16:18:12 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qJx92-0002ts-6a for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Jul 2023 16:18:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJx89-0007nN-CE; Thu, 13 Jul 2023 10:17:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJx85-0007my-Cq for emacs-devel@gnu.org; Thu, 13 Jul 2023 10:17:13 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJx82-0000JY-Lv for emacs-devel@gnu.org; Thu, 13 Jul 2023 10:17:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.com; s=s31663417; t=1689257825; x=1689862625; i=dimech@gmx.com; bh=Xwq0RLgq1IcumE2tlwGDW8vdg5aR/OvAxjL8ic/1nxk=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=Uvo7vz1NdQGJpF4xtS11D4BvL8D6PHon/P1izAROZU19YCHS1rnjo+jfKuiwGnE5w/4zGjX mKA55B2poydYM/zqWOSh0Gfd1Y589Yz5To1VvGr/syBPPwLyVfxWNmoCGJd2AeCnU1PqDB9v+ 3GmykxcVKOYYsTQlrhgNR68BybaSn5xIrM6/isN6nsQfAJXOqNG45Wqk/v/FORbhdJ89D9Vpk mqHdoGow2W+kRCayJD9CQ2gjc71KHPb+wjjObCrWg1RDV7HcytfB0TMp8bjzxlJz7rnJBzqMq QtHjbvFSUafrZIahmwZ/dI41gvkasW/AYHAzXuCP/7Uuzk0rf5pQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [92.251.127.164] ([92.251.127.164]) by web-mail.gmx.net (3c-app-mailcom-bs01.server.lan [172.19.170.58]) (via HTTP); Thu, 13 Jul 2023 16:17:05 +0200 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:G1rRxPgGCQTKfX39uVt3FvDJhAm+kZJxHJV1Sr0N8sW4jM7tcUEaRayInxso5chN+z4yX TPpG9TNetOJ2S1xDtlxWUKPrUgcPkKXGjErXgnOMNKRMOYb8R/24KWQdAIJ9C9/tcpCDNI+GpE/H B/FZt1my/hrSPbHF6g/hd4NfELd02PG3B4APmh4EZAUZDPCQx+FTm+z0aIPnHIACVdM3HmBTsu29 Rbtm4lkK+BpV+clvYHEyjnGJpTqkALF2/u0s7ea8lqKySUTqUpr/SoHBlgEUwSblYrZ9+nAF3gJO os= UI-OutboundReport: notjunk:1;M01:P0:yttEu5hB6ZE=;w3PeG+tGnoq7S0km5vWJQI/iH1S kVWZcSIzIHdtTruvCYl8MSPtQzf+wq3H1Vupj7UezAqj4vrk6EenW1paUEHiUiHotDnR5Sl/M rz8kSqOGMzPhFfk8yMwRFESRSjcGa0y815z2WMx/1ZdJmw5beiuy1ZN39MaFeIfEPSlaEeptj i8bYW7xJvi17OyTdZ5MjDZyj6+O15Qm6YyJDzMrS6UJ5tWFIbZRjuWKDu41j6rqGlftWZemwn Dm6ayjw7pKsejDl4EJhIqjM6JKkSoEwHXsMerqr2HvaN3t2AEGkbh2iGXUbVdISJSrtGZd5Rs bkKU6yq9rtEBQGmHppgZzxh4l8ET1sgQsuIiSs/lz06C4ERN6G06CZwFt6ReOAu5CRicGeCkF IgLk+cfgM1uZtA9AcoNOGujp9DJwU7WiUZrlpVgVx1WFW2EXOQOx8pin3YoeYVKCYkWTKrGR1 vkyp9S2PSoc132/x633mKTnDdS+TXOZbO1mlpWexYyNy3QS5ky7dUoS4FJ7b2g6I7gxTcHEoi 4AvwdHoiBy36/ZMb39QK2/bnIK7pEHYgtPV2sLumGGbM7MqPG1OeXn2jwR8lwcf7JHXTWrJXx eOboqhV19INc32/B5D5/GRlRb5Jz22dKgTCNq8GzTvZq55nBVvVzYvzAaU4qppaePyDMdKeMF 9QcgFyxqEC9D9cnDXUXuBhF8yQlzr+JDmOcquBH9FUXuLoNaVMGNp8EP0PtEarZryxFg/s09E boXVI14IliYFQFxnzHdcGMoSJUu0B3USyHwLykuO6xfFcnfLtRbGEgJuNxo1CjgmM/GbJ0Sn Received-SPF: pass client-ip=212.227.15.18; envelope-from=dimech@gmx.com; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.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_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307821 Archived-At: > Sent: Friday, July 14, 2023 at 1:35 AM > From: "Alan Mackenzie" > To: emacs-devel@gnu.org > Subject: The poor quality of Emacs's backtraces > > Hello, Emacs. > > On running the test suite (make check) on my development version, I > recently got lots of errors and backtraces in the files.log. This is > fair enough. > > What's not good is the message that precedes (or, in the test suite > follows) the backtrace. In the current instance, it looks like: > > Test test-kill-buffer-auto-save-delete-no condition: > (wrong-type-argument listp > #[257 "\300\211\2!\262\1\207" [yes-or-no-p] 4 > "\n\n(fn ARG124 &optional)" t]) > FAILED 376/406 test-kill-buffer-auto-save-delete-no (0.012664 sec) > > So, this says that _something_ wasn't a list, without telling me what th= e > something was. It may have been the value of a variable, or the result > returned from evaluating a form, but the message gives no clue. > > It says "wrong-type-argument", but doesn't say why it's wrong. It > doesn't disclose which primitive detected the fault, though Emacs could > easily do this. > > It doesn't make any effort to say _where_ the bug was detected. If > you're lucky, it might be somewhere in the first function reported in th= e > backtrace, but only if there aren't any frivolous condition-case's in th= e > code which render any remaining backtrace useless. But even if you know > what function it's in, unless that function is short, you don't know > _where_ in that function the error has occurred. The Emacs backtrace > functions don't output any coordinates. This could be done easily, for > example by printing the current position and the total length for a > compiled function (something like 56/120), or by outputting neighbouring > forms for an interpreted function. This would be helpful information fo= r > debugging. > > As already said, the actual backtrace itself is often of little use, due > to the frivolous use of condition-case's. That's even if you stop the > test suite truncating every line at ~70 characters. (Why is this done?) I quite agree that improvements to the backtrace information are needed. It is still enormously difficult to rapidly identify the actual line of co= de causing the problem from the information provided. Most times identificat= ion is done only because of experience than anything else - certainly not a productive way to work. =2D---- Christopher Dimech Administrator General - Naiad Informatics - Gnu Project Society has become too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org > Currently the first few lines of my backtrace look like: > > Test test-kill-buffer-auto-save-delete-no backtrace: > {comp-spill-lap-function} #f(compiled-function (form) "Byte-compile FO= RM, spilling data from the byte compiler." #)(= (lambda (arg124 &optional) (let ((f #'yes-or-no-p)) (funcall f arg124)))) > apply({comp-spill-lap-function} #f(compiled-function (form) "Byte-comp= ile FORM, spilling data from the byte compiler." #) (lambda (arg124 &optional) (let ((f #'yes-or-no-p)) (funcall f arg12= 4))) nil) > comp-spill-lap-function((lambda (arg124 &optional) (let ((f #'yes-or-n= o-p)) (funcall f arg124)))) > comp-spill-lap((lambda (arg124 &optional) (let ((f #'yes-or-no-p)) (fu= ncall f arg124)))) > comp--native-compile((lambda (arg124 &optional) (let ((f #'yes-or-no-p= )) (funcall f arg124))) nil "/tmp/test-nativecomp-cache-Dmx7GP/30.0.50-7a5= 6150c...") > comp-trampoline-compile(yes-or-no-p) > comp-subr-trampoline-install(yes-or-no-p) > {test-overlay-regions} #f(compiled-function () #)() > test-kill-buffer-auto-save(110 {test-kill-buffer-auto-save} #f(compile= d-function () #)) > {test-kill-buffer-auto-save} #f(compiled-function () #)() > > (The symbols in braces are an enhancement I'm currently working on to gi= ve > more information for anonymous functions.) > > If anybody can match up the "wrong-type-argument" message to this > backtrace, they're a better hacker than me - What precisely in > comp-spill-lap-function is using some unknown list primitive on the byte > compiled function? > > So, on the principle of using ALL the information that is available, we > might as well disassemble that byte-compiled function, which might give = a > clue: > > \300 byte-constant yes-or-no-p > \211 byte-dup > \2 stack-ref 2 ; ARG124 > ! byte-call 1 > \262\1 stack-set 1 > \207 return > > .... but not much of one. The function is calling yes-or-no-p with its > parameter, and then I think it's returning yes-or-no-p's result. Though > why it's duplicating yes-or-no-p at the top of the stack, then > overwriting it with the result is unclear. In the test > test-kill-buffer-auto-save-delete-no, fancy things are done with cl-letf > on (symbol-function 'yes-or-no-p), so the disassembled function above > probably has something to do with that. > > It's worth pointing out that there doesn't seem to be a way to get Emacs > to disassemble a function, only a symbol with a function value. > > ######################################################################## > > I will eventually track down the cause of the above bug. But it will > have taken me MUCH longer than it would have done, had the missing > information actually been present in the backtrace. I think I might not > be alone in wishing for these things to be improved. > > So I propose that the quality of our backtraces be improved, and nominat= e > myself as the person to do the work. > > -- > Alan Mackenzie (Nuremberg, Germany). > >