From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21196 invoked by alias); 8 Dec 2011 03:41:30 -0000 Received: (qmail 21186 invoked by uid 22791); 8 Dec 2011 03:41:29 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Dec 2011 03:41:14 +0000 Received: by wgbds11 with SMTP id ds11so2093499wgb.12 for ; Wed, 07 Dec 2011 19:41:13 -0800 (PST) Received: by 10.180.4.42 with SMTP id h10mr954991wih.22.1323315672386; Wed, 07 Dec 2011 19:41:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.89.73 with HTTP; Wed, 7 Dec 2011 19:40:31 -0800 (PST) In-Reply-To: <4EDFFBB4.1070007@earthlink.net> References: <4EDEE6D8.8010301@codesourcery.com> <4EDFFBB4.1070007@earthlink.net> From: Hui Zhu Date: Thu, 08 Dec 2011 08:00:00 -0000 Message-ID: Subject: Re: [PATCH] Fix tracepoint tstart again get gdb_assert To: Stan Shebs , Yao Qi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00248.txt.bz2 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 Thanks, Hui On Thu, Dec 8, 2011 at 07:50, Stan Shebs wrote: > On 12/6/11 8:08 PM, Yao Qi wrote: >> >> On 12/06/2011 11:56 PM, Hui Zhu wrote: >>> >>> Hi, >>> >>> I use a gdb tstart again in a section an got: >>> >>> (gdb) tstart >>> (gdb) tstop >>> (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) >>> >> Thanks for this patch! =A0It is related to my previous commit >> >> =A0 [patch 4/8] Download tracepoint locations and track its status >> =A0 http://sourceware.org/ml/gdb-patches/2011-11/msg00337.html >> >>> The reason is: >>> start_tracing: >>> =A0 =A0 =A0 for (loc =3D b->loc; loc; loc =3D loc->next) >>> =A0 =A0 =A0 =A0{ >>> =A0 =A0 =A0 =A0 =A0/* Since tracepoint locations are never duplicated, = `inserted' >>> =A0 =A0 =A0 =A0 =A0 =A0 flag should be zero. =A0*/ >>> =A0 =A0 =A0 =A0 =A0gdb_assert (!loc->inserted); >>> >>> =A0 =A0 =A0 =A0 =A0target_download_tracepoint (loc); >>> >>> =A0 =A0 =A0 =A0 =A0loc->inserted =3D 1; >>> =A0 =A0 =A0 =A0} >>> >>> But in stop_tracing and trace_status_command don't have code to set >>> inserted back to 0. >>> >> Right, I agree that loc->inserted should be cleared on stop_tracing. >> However, I don't know why we have to clear loc->inserted in >> trace_status_command. =A0A few comments below. >> >> > > I agree, stop_tracing should clear loc->inserted, and tstatus should not;= in > general an information-reading/displaying command should not be making st= ate > changes. =A0If the assert triggers without the tstatus patch, then we sho= uld > understand how and why. =A0(We might be missing a reconnection case or so= me > such?) > > Also, I notice that while the testsuite has lots of tstart/tstop sequence= s, > it normally starts a fresh GDB each time, so it was unable to catch this > failure. =A0The patch to fix should add a sequence of a couple trace runs= in a > row to one of the existing test files. > > Stan > > >