From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [testsuite patch]#2 Fix PR threads/19422 regression + Guile regression [Re: [PATCH+doc] Fix PR threads/19422 - show which thread caused stop]
Date: Fri, 22 Jan 2016 20:05:00 -0000 [thread overview]
Message-ID: <20160122200542.GA12621@host1.jankratochvil.net> (raw)
In-Reply-To: <56A276EB.1070208@redhat.com>
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 #1:
(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 1 "xgdb" received signal SIGINT, Interrupt.^M
0x00007ffff5779da0 in sigprocmask () from /lib64/libc.so.6^M
(gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
backtrace^M
#0 0x00007ffff5779da0 in sigprocmask () from /lib64/libc.so.6^M
#1 0x0000000000704e79 in _rl_handle_signal (sig=2) at signals.c:228^M
#2 <signal handler called>^M
#3 0x00007ffff583bfdd in poll () from /lib64/libc.so.6^M
#4 0x00000000005ebf53 in gdb_wait_for_event (block=block@entry=1) at event-loop.c:746^M
#5 0x00000000005ec589 in gdb_do_one_event () at event-loop.c:323^M
#6 0x00000000005ec6be in start_event_loop () at event-loop.c:347^M
#7 0x00000000005e6513 in captured_command_loop (data=data@entry=0x0) at main.c:318^M
#8 0x00000000005e348d in catch_errors (func=func@entry=0x5e6500 <captured_command_loop>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x7e0e6c "", mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:240^M
#9 0x00000000005e7006 in captured_main (data=data@entry=0x7fffffffd5f0) at main.c:1157^M
#10 0x00000000005e348d in catch_errors (func=func@entry=0x5e6970 <captured_main>, func_args=func_args@entry=0x7fffffffd5f0, errstring=errstring@entry=0x7e0e6c "", mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:240^M
#11 0x00000000005e78cb in gdb_main (args=args@entry=0x7fffffffd5f0) at main.c:1165^M
#12 0x000000000046c0a5 in main (argc=<optimized out>, argv=<optimized out>) at gdb.c:32^M
(gdb) PASS: gdb.gdb/selftest.exp: backtrace through signal handler
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
0x00007ffff6b88b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0^M
(gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
backtrace^M
#0 0x00007ffff6b88b10 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0^M
#1 0x00007ffff6db32b7 in GC_wait_marker () from /lib64/libgc.so.1^M
#2 0x00007ffff6da92ba in GC_help_marker () from /lib64/libgc.so.1^M
#3 0x00007ffff6db15ef in GC_mark_thread () from /lib64/libgc.so.1^M
#4 0x00007ffff6b8360a in start_thread () from /lib64/libpthread.so.0^M
#5 0x00007ffff5847a4d in clone () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler
Jan
next prev parent reply other threads:[~2016-01-22 20:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 23:30 [PATCH] Fix PR threads/19422 - show which thread caused stop Pedro Alves
2016-01-14 14:08 ` [PATCH+doc] " Pedro Alves
2016-01-14 16:36 ` Eli Zaretskii
2016-01-14 17:12 ` Pedro Alves
2016-01-14 18:25 ` Eli Zaretskii
2016-01-14 19:00 ` Pedro Alves
2016-01-14 19:06 ` Eli Zaretskii
2016-01-18 15:17 ` Pedro Alves
2016-01-22 16:44 ` Jan Kratochvil
2016-01-22 16:55 ` Pedro Alves
2016-01-22 16:56 ` Jan Kratochvil
2016-01-22 17:30 ` [testsuite patch] Fix PR threads/19422 regression + Guile regression [Re: [PATCH+doc] Fix PR threads/19422 - show which thread caused stop] Jan Kratochvil
2016-01-22 17:31 ` [testsuite patch]#2 " Jan Kratochvil
2016-01-22 18:18 ` [testsuite patch]#3 " Jan Kratochvil
2016-01-22 18:37 ` [testsuite patch]#2 " Pedro Alves
2016-01-22 20:05 ` Jan Kratochvil [this message]
2016-01-22 20:11 ` Pedro Alves
2016-01-22 20:17 ` Pedro Alves
2016-01-22 20:25 ` [commit] " Jan Kratochvil
2016-01-22 20:44 ` Pedro Alves
2016-01-22 20:51 ` [commit#2] " Jan Kratochvil
2016-01-22 20:53 ` Pedro Alves
2016-01-14 16:04 ` [PATCH] Fix PR threads/19422 - show which thread caused stop Yao Qi
2016-01-18 15:24 ` Pedro Alves
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=20160122200542.GA12621@host1.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.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