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: gdb doesn't print Lisp backtrace in some circumstances. Date: Fri, 12 Apr 2024 10:31:53 +0000 Message-ID: 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="30334"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 12 12:33:04 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 1rvEDQ-0007jv-0l for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Apr 2024 12:33:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvECe-0006Tb-OD; Fri, 12 Apr 2024 06:32:16 -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 1rvECc-0006TL-SV for emacs-devel@gnu.org; Fri, 12 Apr 2024 06:32:14 -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 1rvECa-0006qu-Ud for emacs-devel@gnu.org; Fri, 12 Apr 2024 06:32:14 -0400 Original-Received: (qmail 45631 invoked by uid 3782); 12 Apr 2024 12:31:57 +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 12:31:56 +0200 Original-Received: (qmail 32086 invoked by uid 1000); 12 Apr 2024 10:31:53 -0000 Content-Disposition: inline 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:317688 Archived-At: Hello, Emacs. Yesterday I got a core dump from a segmentation fault in Emacs (my development version, not master). I loaded this into gdb inside Emacs to have a look at it. The backtrace command output the C data as it should, but on coming to the Lisp backtrace gave an error message about there needing to be a process running to "do this". (I don't have the exact message any more.) It would seem these fancy Lisp facilities only work when the process that produced them is still running. All the information required to produce this Lisp backtrace is present in the core dump. Would it be possible, perhaps, to modify our .gdbinit to use the running Emacs to process the core dump, or something like that? Extracting useful information from the C backtrace is slow and tedious in the extreme. -- Alan Mackenzie (Nuremberg, Germany).