Re: [PATCH with testcase] Bug 11568 - delete thread-specific breakpoint on the thread exit

[Yao Qi <yao at codesourcery dot com>]

On 07/30/2013 06:33 PM, Muhammad Waqas wrote:
> --- gdb/breakpoint.c	24 Jul 2013 19:50:32 -0000	1.773
> +++ gdb/breakpoint.c	30 Jul 2013 10:20:49 -0000
> @@ -11941,6 +11941,17 @@ breakpoint_auto_delete (bpstat bs)
>      {
>        if (b->disposition == disp_del_at_next_stop)
>          delete_breakpoint (b);
> +    else if (b->thread > 0)
> +      {
> +	/* If breakpoint relates to user created thread Check if it's
> +	   not alive then delete it.  */
> +	struct thread_info *tp = find_thread_id (b->thread);
> +
> +	if ( tp != NULL && (tp->state == THREAD_EXITED
            ^ redundant space after parenthesis.

> +			    || !target_thread_alive (tp->ptid)))
> +	  delete_breakpoint(b);
> +
> +      }
>      }
>    }
>
> Problem was with my test case, now It works with async/non-stop mode.

One more thing below...

> +    # get the id of thread
> +    set thre $expect_out(1,string)
> +    gdb_breakpoint [gdb_get_line_number "line # 13"]
> +    gdb_breakpoint "main thread $thre"
> +    gdb_test "info break" ".*breakpoint.*(thread $thre)" "Breakpoint set"
> +    gdb_test "thread $thre" "Switching to thread $thre.*" "Thread $thre selected"
> +    gdb_continue_to_breakpoint "line # 13"
> +    set test "thread-specific breakpoint is deleted"
> +    gdb_test_multiple "info breakpoint" $test {

We continue to line 33, and type command 'info breakpoint' to check the 
thread-specific breakpoint is disappeared.  We take an assumption that 
when main thread hits breakpoint on line 33, thread 2 has been exited, 
and GDB has known about it.  However, in async/non-stop mode, it is not 
always true.

The exit of thread 2 happens before thread 1 hits breakpoint on line 33. 
 However, the order of 'thread 1 hits breakpoint' and 'GDB knows about 
thread 2's exit' is not determined, in some runs (in async/non-stop 
mode), I can get the fail below,

continue^M
Continuing.^M
^M
Breakpoint 3, main () at 
../../../../git/gdb/testsuite/gdb.threads/thread-specific-bp.c:33^M
33        return 0; /*line # 13*/^M
(gdb) PASS: gdb.threads/thread-specific-bp.exp: continue to breakpoint: 
line # 13
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
thread 1 hits breakpoint first,

[Thread 0xb7fddb40 (LWP 19876) exited]^M
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
GDB is aware of the exist of thread 2 then, so the thread-specific 
breakpoint is not deleted.

info breakpoint^M
Num     Type           Disp Enb Address    What^M
1       breakpoint     keep y   0x08048487 in main at 
../../../../git/gdb/testsuite/gdb.threads/thread-specific-bp.c:31^M
        breakpoint already hit 1 time^M
2       breakpoint     keep y   0x08048477 in start at 
../../../../git/gdb/testsuite/gdb.threads/thread-specific-bp.c:24^M
        breakpoint already hit 1 time^M
3       breakpoint     keep y   0x080484bf in main at 
../../../../git/gdb/testsuite/gdb.threads/thread-specific-bp.c:33^M
        breakpoint already hit 1 time^M
4       breakpoint     keep y   0x08048487 in main at 
../../../../git/gdb/testsuite/gdb.threads/thread-specific-bp.c:31 thread 2^M
        stop only in thread 2^M
(gdb) FAIL: gdb.threads/thread-specific-bp.exp: thread-specific 
breakpoint is deleted

I suggest that we can add a breakpoint command 'info threads' in the 
breakpoint, which forces GDB to update the list of threads, IMO.  I add 
this below in the test, and didn't see the fail after many runs of test.

    gdb_breakpoint [gdb_get_line_number "line # 13"]

    # Force GDB to update its knowledge on existing threads when this
    # breakpoint is hit.  Otherwise, GDB doesn't realize thread $thre
    # has exited and doesn't remove the thread specific breakpoint.
    gdb_test "commands\ninfo threads\nend" "End with.*" "add breakpoint 
commands"

The patch looks in a good shape now.  I don't have any comments.  Leave 
it to people who can approve it.

--
Yao (éå)