[PATCH with testcase] Bug 11568 - delete thread-specific breakpoint on the thread exit
Yao Qi
yao@codesourcery.com
Wed Jul 31 02:41:00 GMT 2013
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 (é½å°§)
More information about the Gdb-patches
mailing list