From: Tom de Vries <tdevries@suse.de>
To: Andrew Burgess <aburgess@redhat.com>, Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCHv2 3/3] gdb/python: add Corefile.mapped_files method
Date: Wed, 8 Oct 2025 12:36:10 +0200 [thread overview]
Message-ID: <f9130588-76ed-4318-b396-399626ededed@suse.de> (raw)
In-Reply-To: <874is968sb.fsf@redhat.com>
On 10/8/25 11:29, Andrew Burgess wrote:
> Andrew Burgess <aburgess@redhat.com> writes:
>
>> Tom de Vries <tdevries@suse.de> writes:
>>
>>> On 10/7/25 16:38, Andrew Burgess wrote:
>>>> Andrew Burgess <aburgess@redhat.com> writes:
>>>>
>>>>>
>>>>> Thanks for the diagnostic help. I'll work on improving the test to try
>>>>> and catch these cases. If that works, then we might be able to adopt
>>>>> this to help with other tests. Keeping this in mind, I'll add helper
>>>>> functions to lib/gdb.exp.
>>>>
>>>> Hi Tom,
>>>>
>>>> At your leisure, could you check that the patch below resolves the FAIL
>>>> you reported please.
>>>>
>>>
>>> Hi Andrew,
>>>
>>> on Leap 15.6, yes.
>>>
>>> On Tumbleweed, unfortunately no.
>>
>> <snip>
>>
>>> (gdb) PASS: gdb.python/py-corefile.exp: test mapped files data: capture Python based mappings data
>>> shell diff -s /data/vries/gdb/tumbleweed-20251005/build/gdb/testsuite/outputs/gdb.python/py-corefile/py-corefile-out-1.txt /data/vries/gdb/tumbleweed-20251005/build/gdb/testsuite/outputs/gdb.python/py-corefile/py-corefile-out-2.txt
>>> Files /data/vries/gdb/tumbleweed-20251005/build/gdb/testsuite/outputs/gdb.python/py-corefile/py-corefile-out-1.txt and /data/vries/gdb/tumbleweed-20251005/build/gdb/testsuite/outputs/gdb.python/py-corefile/py-corefile-out-2.txt are identical
>>> (gdb) PASS: gdb.python/py-corefile.exp: test mapped files data: diff input and output one
>>> show-build-ids
>>> Objfile Build-Id Core File Build-Id File Name
>>> 91c6abb593a519ecd18e543eaac25f913999b230 91c6abb593a519ecd18e543eaac25f913999b230 /data/vries/gdb/tumbleweed-20251005/build/gdb/testsuite/outputs/gdb.python/py-corefile/py-corefile
>>> Python Exception <class 'KeyError'>: 'corefile'
>>> Error occurred in Python: 'corefile'
>>
>> It looks like there's an objfile discovered via
>> Inferior.progspace.objfiles(), which doesn't correspond to a file mapped
>> into the core file. FYI, I only consider objfiles that are _actual_
>> files, so ignore things like [vdso], etc, and I only consider objfiles
>> with a build-id. I figured that everything meeting this specification
>> had to be something that would appear in the core file...
>>
>> The patch below will make the show-build-ids command a little more
>> resilient, when a file is missing it'll print "missing" in the column
>> now, rather than throwing the KeyError.
>>
>> My guess is we'll find the same file under different names maybe?
>
> Just to follow up, I setup a Tumbleweed VM. I was able to reproduce the
> original issue you reported, but for me, the patch I posted[1] resolves
> the issue.
>
> If you apply the snippet from [2] this should avoid the KeyError
> exception, and should allow us to debug the problem.
>
Hi Andrew,
thanks for following up on this.
I put the gdb.log for Leap 15.6 and Tumbleweed side by side, and noticed
that the difference was presence of glibc debuginfo (in the form of
separate debug info objfiles).
After doing "zypper install glibc-debuginfo" I could reproduce the FAIL
on Leap 15.6. And after doing "dnf debuginfo-install glibc" in a fedora
rawhide container, it also reproduced there.
This fixes it for me in all those 3 cases:
...
diff --git a/gdb/testsuite/gdb.python/py-corefile.py b/gdb/testsuite/gdb.pyt
hon/py-corefile.py
index 01665ef0395..bc8082733bf 100644
--- a/gdb/testsuite/gdb.python/py-corefile.py
+++ b/gdb/testsuite/gdb.python/py-corefile.py
@@ -106,7 +106,7 @@ class ShowBuildIds(gdb.Command):
longest_build_id = 18
for o in objfiles:
- if not o.is_file or o.build_id is None:
+ if not o.is_file or o.build_id is None or o.owner is not
None:
continue
p = pathlib.Path(o.filename).resolve()
b = o.build_id
...
Thanks,
- Tom
> Thanks,
> Andrew
>
> [1] https://inbox.sourceware.org/gdb-patches/87jz166al5.fsf@redhat.com
> [1] https://inbox.sourceware.org/gdb-patches/87bjmi65h4.fsf@redhat.com
>
next prev parent reply other threads:[~2025-10-08 10:36 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 16:03 [PATCH 0/3] Core file Python API Andrew Burgess
2025-09-02 16:03 ` [PATCH 1/3] gdb/python: introduce gdb.Corefile API Andrew Burgess
2025-09-02 16:26 ` Eli Zaretskii
2025-09-16 17:25 ` Tom Tromey
2025-09-23 13:50 ` Andrew Burgess
2025-09-02 16:03 ` [PATCH 2/3] gdb: make structured core file mappings processing global Andrew Burgess
2025-09-16 17:28 ` Tom Tromey
2025-09-02 16:03 ` [PATCH 3/3] gdb/python: add Corefile.mapped_files method Andrew Burgess
2025-09-16 17:54 ` Tom Tromey
2025-09-23 13:52 ` Andrew Burgess
2025-09-23 13:44 ` [PATCHv2 0/3] Core file Python API Andrew Burgess
2025-09-23 13:44 ` [PATCHv2 1/3] gdb/python: introduce gdb.Corefile API Andrew Burgess
2025-10-03 18:56 ` Tom Tromey
2025-10-06 8:54 ` Andrew Burgess
2025-10-06 15:39 ` Tom Tromey
2025-10-06 16:13 ` Andrew Burgess
2025-09-23 13:44 ` [PATCHv2 2/3] gdb: make structured core file mappings processing global Andrew Burgess
2025-10-13 13:57 ` Lancelot SIX
2025-10-13 14:37 ` Andrew Burgess
2025-10-13 15:16 ` Six, Lancelot
2025-10-14 9:12 ` Lancelot SIX
2025-09-23 13:44 ` [PATCHv2 3/3] gdb/python: add Corefile.mapped_files method Andrew Burgess
2025-10-03 19:15 ` Tom Tromey
2025-10-07 6:24 ` Tom de Vries
2025-10-07 12:21 ` Andrew Burgess
2025-10-07 13:08 ` Tom de Vries
2025-10-07 13:26 ` Andrew Burgess
2025-10-07 14:38 ` Andrew Burgess
2025-10-07 15:43 ` Tom de Vries
2025-10-07 16:28 ` Andrew Burgess
2025-10-08 9:29 ` Andrew Burgess
2025-10-08 10:36 ` Tom de Vries [this message]
2025-10-08 14:14 ` Andrew Burgess
2025-10-08 15:43 ` Tom de Vries
2025-10-08 16:03 ` Andrew Burgess
2025-10-16 20:00 ` Tom Tromey
2025-10-17 10:02 ` Andrew Burgess
2025-10-17 13:32 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9130588-76ed-4318-b396-399626ededed@suse.de \
--to=tdevries@suse.de \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox