Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Carl Love via Gdb-patches <gdb-patches@sourceware.org>
To: Tom Tromey <tom@tromey.com>,
	Carl Love via Gdb-patches <gdb-patches@sourceware.org>,
	Simon Marchi <simon.marchi@polymtl.ca>
Cc: pedromfc@br.ibm.com, Ulrich.Weigand@de.ibm.com, rogealve@br.ibm.com
Subject: RE: [PATCH] kill all threadapply processes at end of test
Date: Tue, 18 May 2021 08:29:19 -0700	[thread overview]
Message-ID: <74a4549303369eda07c3488ad0bf9dcfef9e00bc.camel@us.ibm.com> (raw)
In-Reply-To: <8ee8a594f30dcdd1506487ea63ca3f8654c5f112.camel@us.ibm.com>

Tom, Simon, GDB maintainers:

I looked at re-writing the test and using pthread barrier as suggested
by Simon.  I also went back and worked on my previous attempt to track
the pids to be detached, then at the end re-attach the pids.  I was
able to get the second approach to work.  The pthread barrier approach
didn't seem to be very obvious how to implement.

The following patch passes in a string to proc thr_apply_detach.  Each
pid is appended to the string before detaching from the pid.  After the
test is done, the test iterates thru the list of pids attaching to each
one then killing the process.  

The patch has been tested on Power to ensure that it passes
successfully and does not leave any threadapply processes running after
the test finishes. 

Please let me know if you have suggestions on the patch and if it is
accepatble to commit to mainline.  Thanks.

                             Carl 

------------------------------------------------------

gdb/testsuite/ChangeLog:

2021-05-18  Carl Love  <cel@us.ibm.com>

	* gdb.threads/threadapply.exp (thr_apply_detach): Add detach_pids
	argument and return. Add test, gdb_test_multiple, lappend pids to
	detach_pids.
	Add foreach i loop on detach_pids, add gdb_test tests to attach and
	kill each pid.
---
 gdb/testsuite/gdb.threads/threadapply.exp | 26 +++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.threads/threadapply.exp b/gdb/testsuite/gdb.threads/threadapply.exp
index ebc1cf15ad6..d39a9798d7c 100644
--- a/gdb/testsuite/gdb.threads/threadapply.exp
+++ b/gdb/testsuite/gdb.threads/threadapply.exp
@@ -69,7 +69,7 @@ gdb_test "down" "#0.*thread_function.*" "go down and check selected frame"
 # exits due to the command run via thread apply.  Regression test for
 # PR threads/13217.
 
-proc thr_apply_detach {thread_set} {
+proc thr_apply_detach {thread_set detach_pids} {
     with_test_prefix "thread apply $thread_set" {
 	global binfile
 	global break_line
@@ -84,15 +84,30 @@ proc thr_apply_detach {thread_set} {
 	gdb_breakpoint "$break_line"
 	gdb_continue_to_breakpoint "all threads started"
 
+	set test "get inferior pid"
+	set pid -1
+
+	gdb_test_multiple "info inferior 1" "$test" {
+	    -re "process (\[0-9\]*).*" {
+		set pid $expect_out(1,string)
+		pass "$test"
+	    }
+	}
+
+	lappend detach_pids $pid
+
 	gdb_test "thread apply $thread_set detach" "Thread .*"
 	gdb_test "thread" "No thread selected" "switched to no thread selected"
+	return $detach_pids
     }
 }
 
 # Test both "all" and a thread list, because those are implemented as
 # different commands in GDB.
+set detach_pids ""
+
 foreach thread_set {"all" "1.1 1.2 1.3"} {
-    thr_apply_detach $thread_set
+    set detach_pids [thr_apply_detach $thread_set $detach_pids]
 }
 
 # Test killing and removing inferiors from a command run via "thread
@@ -229,3 +244,10 @@ proc kill_and_remove_inferior {thread_set} {
 foreach_with_prefix thread_set {"all" "1.1"} {
     kill_and_remove_inferior $thread_set
 }
+
+# Make sure all of the threadapply processes are terminated
+foreach i  $detach_pids {
+#    puts $i
+    gdb_test "attach $i" ".*" "Attach to $i" ".*A program is being debugged already.*" "y"
+    gdb_test "kill" ".*" "KILL $i" ".*Kill the program being debugged.*" "y"
+}
-- 
2.27.0



  reply	other threads:[~2021-05-18 15:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 16:36 Carl Love via Gdb-patches
2021-05-13 14:30 ` Simon Marchi via Gdb-patches
2021-05-13 15:44 ` Tom Tromey
2021-05-13 18:10   ` Carl Love via Gdb-patches
2021-05-18 15:29     ` Carl Love via Gdb-patches [this message]
2021-05-18 21:56       ` Pedro Franco de Carvalho via Gdb-patches
2021-05-19  0:11         ` Pedro Franco de Carvalho via Gdb-patches
2021-05-20 15:42           ` Carl Love via Gdb-patches
2021-05-20 16:01           ` Carl Love via Gdb-patches
2021-05-24 15:30             ` Carl Love via Gdb-patches
2021-05-29  1:48               ` Simon Marchi via Gdb-patches
2021-06-01 15:42                 ` Carl Love via Gdb-patches
2021-06-01 16:08                   ` Simon Marchi via Gdb-patches
2021-06-02 15:08                     ` Carl Love via Gdb-patches

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=74a4549303369eda07c3488ad0bf9dcfef9e00bc.camel@us.ibm.com \
    --to=gdb-patches@sourceware.org \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=pedromfc@br.ibm.com \
    --cc=rogealve@br.ibm.com \
    --cc=simon.marchi@polymtl.ca \
    --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