From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: gdb doesn't print Lisp backtrace in some circumstances. Date: Fri, 12 Apr 2024 15:03:03 +0300 Message-ID: <86mspyss94.fsf@gnu.org> References: <86pluusunr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21559"; 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 Fri Apr 12 14:04:02 2024 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 1rvFdS-0005Jh-7v for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Apr 2024 14:04:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvFcg-00013v-B4; Fri, 12 Apr 2024 08:03:14 -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 1rvFce-0000yn-NX for emacs-devel@gnu.org; Fri, 12 Apr 2024 08:03:12 -0400 Original-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 1rvFcd-0007br-Sg; Fri, 12 Apr 2024 08:03:11 -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=AuYL/G4jTjZy7d525Olumlz+0yubXAF3oF+PKmBjYKo=; b=gXp/0/qXuStZ rLdQ4VxrcP9XAZW74gZnt7HQ0Smr+1PliK78ScdmL2QTdWlEuITf7qr44GMXnyfDKAcutH76NOAdl DwtA1Gm2+0XReOah+0fGpd6IPPZATak3tya8DK3Vn7kFcaHqx+9s/3QI4IlwjsQvDtY+1rTbvXr3s yBqYB+Mv4iOiqVsYovg+cbMtWD0TOHGHxe1lm3n2QJSxWw2YT/YsqtRYzyw99LH+sxB5Zo1L45U+A 9kZTWFIEzp/1/BdDOwi71aKwZQ/+2kGKYVWB27GOl/+qm8H23XOktw5x2qYttS5u6gLVos1g7Kpxh 9DQvICs97RKkEUd/hg1H4w==; In-Reply-To: (message from Alan Mackenzie on Fri, 12 Apr 2024 11:29:29 +0000) 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:317691 Archived-At: > Date: Fri, 12 Apr 2024 11:29:29 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > But you can reproduce the Lisp backtrace manually (albeit tediously, > > by going over all the calls to Ffuncall, eval_sub and suchlikes, and > > displaying their arg[0]. If it's a symbol, typing xsymbol should show > > you the Lisp function being called. If it is not a symbol, you could > > use xcar/xcdr etc., but that is much more tedious, and I usually give > > up on those frames in the stack. > > I spent a large part of yesterday on this dump. It ends up with a call > (apply apply ...) which goes into an infinite recursion with the number > of arguments increasing by 1 at each stage. I've found the point in the > backtrace where the recursion starts, but it's tedious indeed getting > information out of it. I think I'll have to, though, since I can't see > any other way of debugging this at the moment. One way of avoiding all this tedious manual work is to try to catch the problem with a breakpoint in a running Emacs, not in a core dump. You need to be creative and most probably invest a lot of efforts in trial-and-error to come up with a breakpoint place and condition that on one hand doesn't cause it to trigger too often for false positives, and OTOH doesn't miss the real problem. An easier way is to run Emacs under GDB to begin with, and do what you need to do when it catches the segfault, before dumping core. At that point, you still have a running Emacs, and can call functions inside it, albeit less safely (because when Emacs is crashing, its Lisp machine could be utterly confused or messed up).