[Bug gdb/31238] FAIL: gdb.python/py-inferior.exp: test repr of an invalid thread

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31238

--- Comment #3 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=98138c62cd7f721af132f9b24f274332fd8bf079

commit 98138c62cd7f721af132f9b24f274332fd8bf079
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Fri Jan 12 16:08:14 2024 +0000

    gdb/testsuite: fix failure in gdb.python/py-inferior.exp

    After this commit:

      commit 1925bba80edd37c2ef90ef1d2c599dfc2fc17f72
      Date:   Thu Jan 4 10:01:24 2024 +0000

          gdb/python: add gdb.InferiorThread.__repr__() method

    failures were reported for gdb.python/py-inferior.exp.

    The test grabs a gdb.InferiorThread object representing an inferior
    thread, and then, later in the test, expects this Python object to
    become invalid when the inferior thread has exited.

    The gdb.InferiorThread object was obtained from the list returned by
    calling gdb.Inferior.threads().

    The mistake I made in the original commit was to assume that the order
    of the threads returned from gdb.Inferior.threads() somehow reflected
    the thread creation order.  Specifically, I was expecting the main
    thread to be first in the list, and "other" threads to appear ... not
    first.

    However, the gdb.Inferior.threads() function creates a list and
    populates it from a map.  The order of the threads in the returned
    list has no obvious relationship to the thread creation order, and can
    vary from host to host.

    On my machine the ordering was as I expected, so the test passed for
    me.  For others the ordering was not as expected, and it just happened
    that we ended up recording the gdb.InferiorThread for the main thread.

    As the main thread doesn't exit (until the test is over), the
    gdb.InferiorThread object never became invalid, and the test failed.

    Fixed in this commit by taking more care to correctly find a non-main
    thread.  I do this by recording the main thread early on (when there
    is only one inferior thread), and then finding any thread that is not
    this main thread.

    Then, once all of the secondary threads have exited, I know that the
    second InferiorThread object I found should now be invalid.

    The test still passes for me, and I believe this should fix the issue
    for everyone else too.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31238

-- 
You are receiving this mail because:
You are on the CC list for the bug.