[PATCH] Force to update thread list in queue-signal.exp

[PATCH] Force to update thread list in queue-signal.exp

[Yao Qi]

Hi,
I see the following fail on arm-linux-gnueabi testing,

thread 2^M
Thread ID 2 not known.^M
^^^^^^^^^^^^^^^^^^^^^^
(gdb) PASS: gdb.threads/queue-signal.exp: thread 2
bt^M
(gdb) FAIL: gdb.threads/queue-signal.exp: determine thread functions
gdb/testsuite:

The output "Thread ID 2 not known" doesn't cause a fail because no
pattern to match the output, but the message "Thread ID 2 not known" is
still unexpected.  This patch is to force to issue command "info threads"
in order to update thread list.  On the other hand, this patch is also
to match the output of "thread 2" to make the failure, if any, more
obvious.

2014-09-25  Yao Qi  <yao@codesourcery.com>

	* gdb.threads/queue-signal.exp: Execute command "info threads".
	Match the output of "thread 2".
---
 gdb/testsuite/gdb.threads/queue-signal.exp | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.threads/queue-signal.exp b/gdb/testsuite/gdb.threads/queue-signal.exp
index 207073d..ae50c2e 100644
--- a/gdb/testsuite/gdb.threads/queue-signal.exp
+++ b/gdb/testsuite/gdb.threads/queue-signal.exp
@@ -34,10 +34,14 @@ gdb_test "handle SIGABRT stop print pass"
 gdb_breakpoint "all_threads_running"
 gdb_continue_to_breakpoint "all_threads_running"
 
+# Make sure thread list is up-to-date (in case remote targets have not
+# yet reported thread creation events).
+gdb_test "info threads"
+
 # Find out which of threads 2,3 are for sigusr1,2.
 set sigusr1_thread 0
 set sigusr2_thread 0
-gdb_test "thread 2"
+gdb_test "thread 2" "Switching to .*"
 gdb_test_multiple "bt" "determine thread functions" {
     -re "sigusr1.*$gdb_prompt $" {
 	set sigusr1_thread 2
-- 
1.9.3

Re: [PATCH] Force to update thread list in queue-signal.exp

[Yao Qi]

Yao Qi <yao@codesourcery.com> writes:

> 2014-09-25  Yao Qi  <yao@codesourcery.com>
>
> 	* gdb.threads/queue-signal.exp: Execute command "info threads".
> 	Match the output of "thread 2".

Ping.

-- 
Yao (齐尧)

Re: [PATCH] Force to update thread list in queue-signal.exp

[Pedro Alves]

On 10/07/2014 02:53 PM, Yao Qi wrote:
> Yao Qi <yao@codesourcery.com> writes:
> 
>> 2014-09-25  Yao Qi  <yao@codesourcery.com>
>>
>> 	* gdb.threads/queue-signal.exp: Execute command "info threads".

This part should no longer be necessary:

 https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html

>> 	Match the output of "thread 2".

Thanks,
Pedro Alves

Re: [PATCH] Force to update thread list in queue-signal.exp

[Yao Qi]

Pedro Alves <palves@redhat.com> writes:

>>> 	* gdb.threads/queue-signal.exp: Execute command "info threads".
>
> This part should no longer be necessary:
>
>  https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html

Thanks for the pointer.  I didn't follow this patch series because
ThunderBird hides it under other unrelated thread.

Looks other tests don't have to pull thread list explicitly, IIUC, so we
can remove them.  How about the patch below?

-- 
Yao (齐尧)

Subject: [PATCH] No longer pull thread list explicitly

As the result of the patch below, GDB updates thread list when a stop is
presented to user.  The tests don't have to fetch thread list explicitly.

  [PATCH 3/3] Fix non-stop regressions caused by "breakpoints always-inserted off" changes
  https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html

This patch is to remove the test code updating thread list.

Run these three tests many times on arm-linux-gnueabi and x86-linux.
No regressions.

gdb/testsuite:

2014-10-08  Yao Qi  <yao@codesourcery.com>

	* gdb.threads/attach-into-signal.exp (corefunc): Don't execute
	 command "info threads".
	* gdb.threads/thread-find.exp: Likewise.
	* gdb.threads/linux-dp.exp: Don't check the condition
	$threads_created equals to zero.

diff --git a/gdb/testsuite/gdb.threads/attach-into-signal.exp b/gdb/testsuite/gdb.threads/attach-into-signal.exp
index d77380b..277a9d0 100644
--- a/gdb/testsuite/gdb.threads/attach-into-signal.exp
+++ b/gdb/testsuite/gdb.threads/attach-into-signal.exp
@@ -102,15 +102,6 @@ proc corefunc { threadtype executable } {
 			# that by peeking at the thread's siginfo.
 			# SIGALRM is 14, SIGSTOP is 19.
 
-			# With remote targets, we need to pull the
-			# thread list explicitly before GDB even knows
-			# about thread 2.
-			set test2 "pull thread list"
-			gdb_test_multiple "info threads" $test2 {
-			    -re "\r\n$gdb_prompt $" {
-			    }
-			}
-
 			set test2 "thread apply 2 print \$_siginfo.si_signo"
 			gdb_test_multiple $test2 $test2 {
 			    -re " = 14\r\n$gdb_prompt $" {
diff --git a/gdb/testsuite/gdb.threads/linux-dp.exp b/gdb/testsuite/gdb.threads/linux-dp.exp
index 8fa8288..f4099fe 100644
--- a/gdb/testsuite/gdb.threads/linux-dp.exp
+++ b/gdb/testsuite/gdb.threads/linux-dp.exp
@@ -104,14 +104,7 @@ for {set i 0} {$i < 5} {incr i} {
 	-re "$gdb_prompt $" {
 	}
     }
-    if { $threads_created == 0 } {
-	# Not all targets announce new threads as they are created.
-	# For example, the GDB
-	# remote protocol target only finds out about threads when
-	# they actually report some event like a breakpoint hit,
-	# or when the user types 'info threads'.
-	unsupported "create philosopher: $i"
-    } elseif { $threads_created == 1 } {
+    if { $threads_created == 1 } {
 	if { $expect_manager < 0 } {
 	    set expect_manager 0
 	}
diff --git a/gdb/testsuite/gdb.threads/thread-find.exp b/gdb/testsuite/gdb.threads/thread-find.exp
index 25f2856..3e82989 100644
--- a/gdb/testsuite/gdb.threads/thread-find.exp
+++ b/gdb/testsuite/gdb.threads/thread-find.exp
@@ -29,10 +29,6 @@ runto_main
 gdb_breakpoint [gdb_get_line_number "linuxthreads.exp: info threads 2"]
 gdb_continue_to_breakpoint "main thread's sleep"
 
-# Make sure thread list is up-to-date (in case remote targets have not yet
-# reported thread creation events)
-gdb_test "info threads"
-
 # Create thread names.
 gdb_test "thread apply 1 thread name threadname_1" \
     "Thread 1 .*" \

Re: [PATCH] Force to update thread list in queue-signal.exp

[Pedro Alves]

On 10/09/2014 01:21 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>>>> 	* gdb.threads/queue-signal.exp: Execute command "info threads".
>>
>> This part should no longer be necessary:
>>
>>  https://sourceware.org/ml/gdb-patches/2014-09/msg00734.html
> 
> Thanks for the pointer.  I didn't follow this patch series because
> ThunderBird hides it under other unrelated thread.

Odd.  I sent it as a separate thread with git send-email.
The cover letter has no In-Reply-To or References headers even.
My Thunderbird doesn't put it under any other thread, and the
archives have it as a separate thread too.

But now that you mention this, I had found odd that this series

  https://sourceware.org/ml/gdb-patches/2014-09/msg00772.html

had been sent as reply to an unrelated old email from 2012, but,
now that I look at the raw headers of Jose's email, it doesn't seem
to have been send as response to any email after all, but rather
it's my Thunderbird that's acting up.  gmane doesn't nest that under
what my TB is nesting it under either, this:

  http://thread.gmane.org/gmane.comp.gdb.patches/75048

Jose's mail's headers have:

 Message-Id: <1411724905-31234-1-git-send-email-jose.marchesi@oracle.com>
 In-Reply-To: <no>
 References: <no>

And the message my TB nests it under has:

 Message-Id: <1334741131-29283-1-git-send-email-Hilfinger@adacore.com>
 In-Reply-To: <no>
 References: <no>

I wondered if those "<no>"s triggered that, but my email doesn't
have it, so that wouldn't explain it for your case.

Sounds like we're both hitting the same Thunderbird bug still.
I'm running version 31.1.1 on Fedora 20.

> Looks other tests don't have to pull thread list explicitly, IIUC, so we
> can remove them.  How about the patch below?

Thanks!  I intended to do something like that myself after a period.

Looks good, please push.

Thanks,
Pedro Alves

Re: [PATCH] Force to update thread list in queue-signal.exp

[Yao Qi]

Pedro Alves <palves@redhat.com> writes:

> Sounds like we're both hitting the same Thunderbird bug still.
> I'm running version 31.1.1 on Fedora 20.

I am running on Fedora 20 too, but with an older ThunderBird.  This
problem bites me from time to time.  Emacs/gnus doesn't have such
problem, and I am using both of them.

>
>> Looks other tests don't have to pull thread list explicitly, IIUC, so we
>> can remove them.  How about the patch below?
>
> Thanks!  I intended to do something like that myself after a period.

Patch is pushed in.

-- 
Yao (齐尧)