diff mbox

[testsuite] #2 Fix PR threads/19422 regression + Guile regression [Re: [PATCH+doc] Fix PR threads/19422 - show which thread caused stop]

Message ID 20160122173100.GA5990@host1.jankratochvil.net
State New, archived
Headers

Commit Message

Jan Kratochvil Jan. 22, 2016, 5:31 p.m. UTC 
  [ now with the patch]
On Fri, 22 Jan 2016 18:30:20 +0100, Jan Kratochvil wrote:

On Thu, 14 Jan 2016 15:08:40 +0100, Pedro Alves wrote:
> gdb/ChangeLog:
> 2016-01-14  Pedro Alves  <palves@redhat.com>
> 
> 	* NEWS: Mention that GDB now displays the ID and name of the
> 	thread that hit a breakpoint or received a signal.
> 	* break-catch-sig.c (signal_catchpoint_print_it): Use
> 	maybe_print_thread_hit_breakpoint.
> 	* break-catch-syscall.c (print_it_catch_syscall): Likewise.
> 	* break-catch-throw.c (print_it_exception_catchpoint): Likewise.
> 	* breakpoint.c (maybe_print_thread_hit_breakpoint): New function.
> 	(print_it_catch_fork, print_it_catch_vfork, print_it_catch_solib)
> 	(print_it_catch_exec, print_it_ranged_breakpoint)
> 	(print_it_watchpoint, print_it_masked_watchpoint, bkpt_print_it):
> 	Use maybe_print_thread_hit_breakpoint.
> 	* breakpoint.h (maybe_print_thread_hit_breakpoint): Declare.
> 	* gdbthread.h (show_thread_that_caused_stop): Declare.
> 	* infrun.c (print_signal_received_reason): Print which thread
> 	received signal.
> 	* thread.c (show_thread_that_caused_stop): New function.

There was already before a regression if --with-guile (which is default if
Guile is found) was used:

backtrace^M
#0  0x00007ffff6078da0 in __sigprocmask (how=2, set=0x7fffffffcc40, oset=0x0) at ../sysdeps/unix/sysv/linux/x86_64/sigprocmask.c:39^M
#1  0x0000000000966ce9 in _rl_handle_signal (sig=2) at signals.c:228^M
#2  0x0000000000966c05 in rl_signal_handler (sig=2) at signals.c:149^M
#3  <signal handler called>^M
#4  0x00007ffff613afc0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84^M
#5  0x00000000007d9a88 in gdb_wait_for_event (block=1) at event-loop.c:746^M
#6  0x00000000007d8e87 in gdb_do_one_event () at event-loop.c:323^M
#7  0x00000000007d8ed8 in start_event_loop () at event-loop.c:347^M
#8  0x00000000007da9dc in cli_command_loop (data=0x0) at event-top.c:186^M
#9  0x00000000007d0b4c in current_interp_command_loop () at interps.c:317^M
#10 0x00000000007d1f56 in captured_command_loop (data=0x0) at main.c:318^M
#11 0x00000000007cd6c9 in catch_errors (func=0x7d1f3b <captured_command_loop>, func_args=0x0, errstring=0x1167f75 "", mask=RETURN_MASK_ALL) at exceptions.c:240^M
#12 0x00000000007d3514 in captured_main (data=0x7fffffffd600) at main.c:1157^M
#13 0x00000000007cd6c9 in catch_errors (func=0x7d23d5 <captured_main>, func_args=0x7fffffffd600, errstring=0x1167f75 "", mask=RETURN_MASK_ALL) at exceptions.c:240^M
#14 0x00000000007d353d in gdb_main (args=0x7fffffffd600) at main.c:1165^M
#15 0x000000000049ae8c in main (argc=5, argv=0x7fffffffd708) at gdb.c:32^M
(gdb) PASS: gdb.gdb/selftest.exp: backtrace through signal handler
->
backtrace^M
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185^M
#1  0x00007ffff6db32b7 in GC_wait_marker () at pthread_support.c:2036^M
#2  0x00007ffff6da92ba in GC_help_marker (my_mark_no=my_mark_no@entry=4) at mark.c:1168^M
#3  0x00007ffff6db15ef in GC_mark_thread (id=<optimized out>) at pthread_support.c:389^M
#4  0x00007ffff6b8360a in start_thread (arg=0x7ffff337e700) at pthread_create.c:334^M
#5  0x00007ffff5847a4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109^M
(gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler


Additionally this patchset added a new regression:

Program received signal SIGINT, Interrupt.^M
0x00007ffff613afc0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84^M
84      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)^M
(gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process
->
Thread 1 "xgdb" received signal SIGINT, Interrupt.^M
0x00007ffff583bfdd in poll () at ../sysdeps/unix/syscall-template.S:84^M
84      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)^M
(gdb) FAIL: gdb.gdb/selftest.exp: send ^C to child process


OK to check-in the fix for both of these problems?

Tested on x86_64-fedora23-linux-gnu.


Thanks,
Jan
gdb/testsuite/ChangeLog
2016-01-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix testsuite compatibility with Guile.
	* gdb.gdb/selftest.exp (send ^C to child process): Accept also Thread.
	(thread 1): New test for backtrace through signal handler.

Comments

Pedro Alves Jan. 22, 2016, 6:37 p.m. UTC | #1 
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?

Thanks,
Pedro Alves
Jan Kratochvil Jan. 22, 2016, 8:05 p.m. UTC | #2 
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
Pedro Alves Jan. 22, 2016, 8:11 p.m. UTC | #3 
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
Pedro Alves Jan. 22, 2016, 8:17 p.m. UTC | #4 
On 01/22/2016 08:11 PM, Pedro Alves wrote:
> On 01/22/2016 08:05 PM, Jan Kratochvil wrote:

>> 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?

And I notice now that this expects the thread name to be the
the program name:

 -	    -re "Program received signal SIGINT.*$gdb_prompt $" {
 +	    -re "(Thread 1 \"xgdb\"|Program) received signal SIGINT.*$gdb_prompt $" {

Not all targets support thread names, and even those that do, not all
use the program name as default thread name -- I think that's only true
for GNU/Linux, actually.  So I think it's best to not expect that, like:

 	    -re "(Thread .*|Program) received signal SIGINT.*$gdb_prompt $" {
or:
	    -re " received signal SIGINT.*$gdb_prompt $" {

Thanks,
Pedro Alves
diff mbox

Patch

diff --git a/gdb/testsuite/gdb.gdb/selftest.exp b/gdb/testsuite/gdb.gdb/selftest.exp
index 4d55cb5..cdcf981 100644
--- a/gdb/testsuite/gdb.gdb/selftest.exp
+++ b/gdb/testsuite/gdb.gdb/selftest.exp
@@ -436,8 +436,9 @@  proc test_with_self { executable } {
     if ![target_info exists gdb,nointerrupts] {
 	set description "send ^C to child process"
 	send_gdb "\003"
+	# "Thread 1" is displayed iff Guile support is linked in.
 	gdb_expect {
-	    -re "Program received signal SIGINT.*$gdb_prompt $" {
+	    -re "(Thread 1 \"xgdb\"|Program) received signal SIGINT.*$gdb_prompt $" {
 		pass "$description"
 	    }
 	    -re ".*$gdb_prompt $" {
@@ -448,6 +449,9 @@  proc test_with_self { executable } {
 	    }
 	}
     }
+
+    # Switch back to the GDB thread if Guile support is linked in.
+    gdb_test "thread 1" {\[Switching to thread 1 .*\].*}
     
     set description "send SIGINT signal to child process"
     gdb_test "signal SIGINT" \