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: gdb doesn't print Lisp backtrace in some circumstances. Date: Fri, 12 Apr 2024 13:18:15 +0000 Message-ID: References: <86pluusunr.fsf@gnu.org> <86mspyss94.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16641"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 12 15:19:18 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 1rvGoI-000428-4o for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Apr 2024 15:19:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvGnR-00018z-Hn; Fri, 12 Apr 2024 09:18:25 -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 1rvGnP-00018g-QP for emacs-devel@gnu.org; Fri, 12 Apr 2024 09:18:23 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rvGnN-0005dv-HN for emacs-devel@gnu.org; Fri, 12 Apr 2024 09:18:23 -0400 Original-Received: (qmail 34096 invoked by uid 3782); 12 Apr 2024 15:18:18 +0200 Original-Received: from muc.de (pd953ac5b.dip0.t-ipconnect.de [217.83.172.91]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 12 Apr 2024 15:18:17 +0200 Original-Received: (qmail 701 invoked by uid 1000); 12 Apr 2024 13:18:15 -0000 Content-Disposition: inline In-Reply-To: <86mspyss94.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.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_PASS=-0.001, SPF_PASS=-0.001 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:317693 Archived-At: Hello, Eli. On Fri, Apr 12, 2024 at 15:03:03 +0300, Eli Zaretskii wrote: > > 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. That won't work for this situation. The seg fault is happening whilst loading isearch.el from loadup.el during early building. I don't have a running Emacs to probe it with. > 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. Yes. This is the curse of using debuggers, the difficulty of getting breakpoints placed effectively. GDB is quite good in this respect, since you can put a condition on any breakpoint to reduce the false positives. > 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). -- Alan Mackenzie (Nuremberg, Germany).