From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 4C96D3858C5E; Fri, 15 Mar 2024 16:41:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4C96D3858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1710520901;
	bh=BMiLqsxK/n+anfjmLJOFjVq7ntgmcaRhW+fOeNMlMus=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ymd4KlQzhfSCJGZKhzme/mMwUx0U8C4Rgkwg8mEVPQmHWnQ5vPcdaVoZOCSn0eIKh
	 ZwJfTzfVYU7JXCRFb3BP3Yn3JBIBTUyAthdEd796gtelilgBBHwMA7HezG99/9cr36
	 N3rSL0nrKOrV2EgjBw6L/4KoTxeCidvWB+l/zQGs=
From: "cel at linux dot ibm.com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug testsuite/31312] attach-many-short-lived-threads gives
 inconsistent results
Date: Fri, 15 Mar 2024 16:41:39 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cel at linux dot ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: cel at linux dot ibm.com
X-Bugzilla-Target-Milestone: 15.1
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-31312-4717-Br9GCGbuw6@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-31312-4717@http.sourceware.org/bugzilla/>
References: <bug-31312-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

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

--- Comment #15 from Carl E Love <cel at linux dot ibm.com> ---

Tommy:

I spent some time trying to dig into this again.

The gdb log says that it detached from the pid.  I don't find any way to ve=
rify
that.  I don't see any gdb attached thread status command that would verify=
 it.=20

I did try putting in sleep commands in the hope that if it was a race of tr=
ying
to delay the attach a bit more to give time for the detach to really finish=
.=20
But that didn't make any difference.

I was able to get the expect script to issue the ps command on the fail so I
can go look at the processes running:

                   if {$eperm} {
                        xfail "$test (EPERM)"
                        # The attach failed.  No point in doing the rest=20=
=20=20=20=20=20=20=20
                        # of the tests since we are not attached?  So=20=20=
=20=20=20=20=20=20=20=20=20
                        # should we either 1) exit the test; or 2)=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
                        # try again with a new testpid?=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
                        puts "CARLL, xfail EPERM, testpid $testpid"

                        gdb_test "detach" "Detaching from.*"

                        # try to figure out the state of the process=20=20=
=20=20=20=20=20=20=20=20=20=20
                        set prompt {\$ $}
                        spawn bash
                        expect -re $prompt
                        send "ps -eaf \r"
                        expect {
                            "aa" {
                                send "CARLL, Output\r"
                            }
                            -re $prompt
                        }
                        expect eof

Based on the ps output, it does look like the process is still running.

With regards to my patch, you mentioned that you were concerned about leavi=
ng
the process running and then starting another one. Perhaps we should kill t=
he
process that we couldn't attach to then create a new one?  That way we
shouldn't=20
be leaving anything running.  Specifically:

                -re "$gdb_prompt $" {
                    if {$eperm} {
                        xfail "$test (EPERM)"
                        # Kill the current process and start a new one    <<
NEW=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20
                        kill_wait_spawned_process $test_spawn_id          <<
NEW

                        # The attach failed.  No point in doing the rest=20=
=20=20=20=20=20=20=20
                        # of the tests since we are not attached?  So=20=20=
=20=20=20=20=20=20=20=20=20
                        # should we either 1) exit the test; or 2)=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
                        # try again with a new testpid?=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
                        puts "CARLL, xfail EPERM, testpid $testpid"

                        # Try a new process=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20
                        set test_spawn_id [spawn_wait_for_attach $binfile]
                        set testpid [spawn_id_get_pid $test_spawn_id]
                    } else {
                        pass $test
                    }
                }

We could just end the test as you suggested.  That is still another option.=
=20=20

Thoughts on killing the previous thread and then creating a new one?  Or wo=
uld
you still prefer just ending the test?

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