From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2165 invoked by alias); 9 Dec 2011 14:34:07 -0000 Received: (qmail 2004 invoked by uid 22791); 9 Dec 2011 14:34:07 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Dec 2011 14:33:53 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RZ1WL-0001BY-2z from pedro_alves@mentor.com ; Fri, 09 Dec 2011 06:33:53 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Dec 2011 14:33:51 +0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix tracepoint tstart again get gdb_assert Date: Fri, 09 Dec 2011 15:41:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.7.2; x86_64; ; ) Cc: Yao Qi , Hui Zhu , Stan Shebs References: <4EE1DA93.7080903@codesourcery.com> In-Reply-To: <4EE1DA93.7080903@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112091433.49620.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2011-12/txt/msg00289.txt.bz2 On Friday 09 December 2011 09:53:23, Yao Qi wrote: > On 12/08/2011 11:40 AM, Hui Zhu wrote: > > Hi guys, > > > > I am sorry that I didn't talk clear about the issue of tstatus. > > When we use tstatus, it can auto set the tracepoint back to stop when > > it full or got error. Then user can use tstart without tstop that set > > loc->inserted. So we will still meet that issue if we just set > > loc->inserted in tstop. > > > > For examp: > > This gdb is just set loc->inserted in tstop but not tstatus. > > (gdb) tstart > > (gdb) tstop > > (gdb) tstart > > (gdb) tstop > > (gdb) tstart > > xxx > > xxx > > (gdb) tstatus > > Trace stopped because the buffer was full. > > Buffer contains 0 trace frames (of 49072 created total). > > Trace buffer has 908408 bytes of 10414080 bytes free (91% full). > > Trace will stop if GDB disconnects. > > Not looking at any trace frame. > > (gdb) tstart > > ../../src/gdb/tracepoint.c:1770: internal-error: start_tracing: > > Assertion `!loc->inserted' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Quit this debugging session? (y or n) n > > > > ../../src/gdb/tracepoint.c:1770: internal-error: start_tracing: > > Assertion `!loc->inserted' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Create a core file of GDB? (y or n) n > > > > This is the 2nd version of my patch. Compared with 1st version (sent > four hours ago), this version covers more cases. In this patch, a new > observer `trace_stopped' is added. In stop_tracing and > target_get_trace_status, observer `trace_stopped' is notified, and then, > `inserted' flag is cleared. This looks more clear than version 1. I think this is overkill. It's just impossible to be absolutely certain a trace run is currently ongoing. If you do "tstatus;tstart", the trace can still stop between the two commands. Is there anything that we benefit from clearing the inserted flag on tstatus? I think that if we clear them only, and always, at "tstart" time, we're good. We already clear all the inserted flag of all breakpoints and tracepoints on target open ("target remote ...", etc.), from within breakpoint.c:breakpoint_init_inferior -- that's why you don't see this assertion if you disconnect and reconnect, and find the target was tracing. So I think we should just clear the inserted flag of all tracepoints in start_tracing, right after the target_trace_init call. Possibly even merge the new loop with the existing loop that downloads tracepoints. -- Pedro Alves