GNU bug report logs - #75599
31.0.50; scratch/igc: crash on commit 92ccf1c after opening file and REPL

Previous Next

Full log

Message #14 received at 75599 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: oliver.reiter <at> snapdragon.cc, 75599 <at> debbugs.gnu.org
Subject: Re: bug#75599: 31.0.50;
 scratch/igc: crash on commit 92ccf1c after opening file and REPL
Date: Sat, 18 Jan 2025 09:54:29 +0200

> Date: Sat, 18 Jan 2025 02:11:51 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: 75599 <at> debbugs.gnu.org, Oliver Reiter <oliver.reiter <at> snapdragon.cc>
> 
> General GDB question (CCing Eli because he knows much more than I do
> about GDB): is there some way to run "find", but have it search all the
> memory ranges that are present in the relevant core dump?

I seldom use 'find', and core dumps even more seldom, but shouldn't
GDB be able to search memory of the debuggee regardless of whether it
came from the core file or from a live process?  Or am I
misunderstanding the question?

> Or, at least, find out which ranges are present?  I know "objdump -h"
> provides that information, but it's not the most friendly of formats.
> 
> I've usually just resorted to inspecting the core dump in hexl mode for
> that, but that's hardly ideal.  It would be helpful in this case because
> I don't have (or want) access to the core dump file produced by someone
> else's Emacs session.

If the problem is access to someone else's core file, then why cannot
you give instructions for how to search?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.