From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21416 invoked by alias); 31 Jul 2013 02:41:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21386 invoked by uid 89); 31 Jul 2013 02:41:23 -0000 X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_05,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 31 Jul 2013 02:41:22 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1V4MLi-0006m1-4P from Yao_Qi@mentor.com ; Tue, 30 Jul 2013 19:41:14 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 19:41:13 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Tue, 30 Jul 2013 19:41:13 -0700 Message-ID: <51F8791A.1090704@codesourcery.com> Date: Wed, 31 Jul 2013 02:41:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Muhammad Waqas CC: , , Subject: Re: [PATCH with testcase] Bug 11568 - delete thread-specific breakpoint on the thread exit References: <51F619CE.5040407@codesourcery.com> <51F633E5.7000302@codesourcery.com> <51F65519.2080806@codesourcery.com> <51F67992.30704@codesourcery.com> <51F7967E.3060900@codesourcery.com> In-Reply-To: <51F7967E.3060900@codesourcery.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-07/txt/msg00805.txt.bz2 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 (齐尧)