From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: The poor quality of Emacs's backtraces Date: Fri, 14 Jul 2023 13:07:00 +0000 Message-ID: References: <3D901B62-4826-4783-B684-968E6890E75A@gmail.com> <6CB5E709-8F5A-4015-9F2C-337A87916C66@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="898"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 14 15:07:55 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 1qKIWY-000AXW-Ll for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Jul 2023 15:07:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKIVr-00086h-Ny; Fri, 14 Jul 2023 09:07:11 -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 1qKIVn-0007zZ-90 for emacs-devel@gnu.org; Fri, 14 Jul 2023 09:07:08 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKIVl-0003Yv-87 for emacs-devel@gnu.org; Fri, 14 Jul 2023 09:07:07 -0400 Original-Received: (qmail 68403 invoked by uid 3782); 14 Jul 2023 15:07:01 +0200 Original-Received: from acm.muc.de (p4fe159b6.dip0.t-ipconnect.de [79.225.89.182]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 14 Jul 2023 15:07:00 +0200 Original-Received: (qmail 2671 invoked by uid 1000); 14 Jul 2023 13:07:00 -0000 Content-Disposition: inline In-Reply-To: <6CB5E709-8F5A-4015-9F2C-337A87916C66@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:307866 Archived-At: Hello, Mattias. On Fri, Jul 14, 2023 at 14:35:32 +0200, Mattias Engdegård wrote: > 14 juli 2023 kl. 12.48 skrev Alan Mackenzie : [ .... ] > The fault is perhaps closer to (my?) home: the bytecode interpreter > doesn't add a stack frame for many built-in ops. For example, (cdr 3) > will signal a `wrong-type-argument` error but `cdr` isn't in the > backtrace. We can't afford to add stack frames for things like cdr. It would make Emacs _far_ too slow. > That is something we could and should fix. At least for some ops it > should be pretty easy, and even a partial remedy would be helpful. > Alan, thank you for bringing this to my attention! My idea for fixing this problem would be to add an extra parameter to the CHECK_LIST (C) macro, the (symbol of) the primitive which is using cdr. This would be output in the backtrace error message. There are only 1,728 occurrences of CHECK_* in the Emacs C sources. Much of the amendment could be automated. > > My enhancement is to store the @dfn{defining symbol} of anonymous > > functions inside the function, whether an interpreted function, or > > either type of compiled function. This symbol is the defun/defmacro > > etc. within which the lambda is defined. > Well, no, this isn't necessarily an improvement. If anything our > function objects are too fat; making them more so isn't what we need. Why? Yesterday evening, the identity of {comp-spill-lap-function} was very helpful in locating the buggy source. Do you have any alternative mechanism in mind for identifying anonymous functions in backtraces? After all, there is nothing particularly wrong with the fatness of our function objects, provided it is not taken to extremes - RAM is cheap and plentiful. -- Alan Mackenzie (Nuremberg, Germany).