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

Previous Next

Full log

Message #32 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 14:28:58 +0200

> Date: Sat, 18 Jan 2025 11:47:27 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: 75599 <at> debbugs.gnu.org, oliver.reiter <at> snapdragon.cc
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> > 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?
> 
> I don't know how to search "all" process memory with GDB.  That's the
> problem.

Is the problem to know what are the START_ADDR and END_ADDR arguments
to the 'find' command?  If so, do the variables set by firstfile.c and
lastfile.c help?

Previous Next

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