This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [testsuite patch]#2 Fix PR threads/19422 regression + Guile regression [Re: [PATCH+doc] Fix PR threads/19422 - show which thread caused stop]
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 22 Jan 2016 20:11:18 +0000
- Subject: Re: [testsuite patch]#2 Fix PR threads/19422 regression + Guile regression [Re: [PATCH+doc] Fix PR threads/19422 - show which thread caused stop]
- Authentication-results: sourceware.org; auth=none
- References: <1451950202-18024-1-git-send-email-palves at redhat dot com> <5697ABE8 dot 7060705 at redhat dot com> <20160122173020 dot GA5946 at host1 dot jankratochvil dot net> <20160122173100 dot GA5990 at host1 dot jankratochvil dot net> <56A276EB dot 1070208 at redhat dot com> <20160122200542 dot GA12621 at host1 dot jankratochvil dot net>
On 01/22/2016 08:05 PM, Jan Kratochvil wrote:
> On Fri, 22 Jan 2016 19:37:31 +0100, Pedro Alves wrote:
>> On 01/22/2016 05:31 PM, Jan Kratochvil wrote:
>>> OK to check-in the fix for both of these problems?
>>
>> I think I'm confused -- the first hunk shows that it's
>> thread 1 that receives the signal; then why do we need
>> the "thread 1" command?
>
> I have looked more at it now and there is a race. The following outputs are
> from unpatched FSF GDB HEAD:
...
>
> racy case #2:
>
> (xgdb) PASS: gdb.gdb/selftest.exp: Set xgdb_prompt
> ^M
> Thread 1 "xgdb" received signal SIGINT, Interrupt.^M
> 0x00007ffff583bfdd in poll () from /lib64/libc.so.6^M
> (gdb) FAIL: gdb.gdb/selftest.exp: send ^C to child process
> signal SIGINT^M
> Continuing with signal SIGINT.^M
> ^C^M
> Thread 2 "xgdb" received signal SIGINT, Interrupt.^M
> [Switching to Thread 0x7ffff3b7f700 (LWP 13227)]^M
So you need to adjust your patch in the bit that matched
"Thread 1", right?
Thanks,
Pedro Alves