Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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
> 


  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