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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 11:47:27 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> 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?

I don't know how to search "all" process memory with GDB.  That's the
problem.  I can do it with objdump and a script, but that's too ugly to
go into our .gdbinit:

define xfindrefs
  gcore core.tmp
  shell objdump -h core.tmp | egrep '^[0-9]' | while read N NAME SIZE START REST; do if [ "$((0x$SIZE))" != 0 ]; then echo "find 0x$START,0x$START + 0x$SIZE,\$needle"; fi; done > find.tmp
  p $needle = $arg0
  shell echo > results.tmp
  set logging file results.tmp
  set logging enabled on
  set logging redirect on
  source find.tmp
  set logging enabled off
  shell grep '^0x' results.tmp | sed -e 's/ .*//g' | sed -e 's/^/x\/32gx /g' | sed -e 's/$/ - 128/g' > find2.tmp
  source find2.tmp
end

>> 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?

I have.  The problem is they're a bit unwieldy.  I'd prefer to say
"xfindrefs 0x7fffb88e48e8", which will output the right data, but create
temporary files.

I've tried hacking igc.c so it can walk the pools and find references to
a specified object.  That works, but it seems MPS isn't very good about
entering the postmortem state when a scan function crashes.  So no luck
in such cases, which would include this one (of course there's no way to
replace the C code and inspect the memory in the GDB session / coredump).

Pip

Previous Next

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