Force to update thread list in queue-signal.exp
Commit Message
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?
Comments
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
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.
@@ -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 $" {
@@ -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
}
@@ -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 .*" \