Re: [PATCHv2 3/3] gdb/python: add Corefile.mapped_files method

Tom de Vries
2025-10-08T10:36:38Z

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
>