From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15825 invoked by alias); 7 Dec 2011 23:50:28 -0000 Received: (qmail 15815 invoked by uid 22791); 7 Dec 2011 23:50:27 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-scoter.atl.sa.earthlink.net (HELO elasmtp-scoter.atl.sa.earthlink.net) (209.86.89.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Dec 2011 23:50:13 +0000 Received: from [70.170.59.51] (helo=macbook2.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RYRFc-00034p-9M for gdb-patches@sourceware.org; Wed, 07 Dec 2011 18:50:12 -0500 Message-ID: <4EDFFBB4.1070007@earthlink.net> Date: Thu, 08 Dec 2011 00:05:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix tracepoint tstart again get gdb_assert References: <4EDEE6D8.8010301@codesourcery.com> In-Reply-To: <4EDEE6D8.8010301@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da9408b43245eb77b09caf089fc842a9c79af350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00243.txt.bz2 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! It is related to my previous commit > > [patch 4/8] Download tracepoint locations and track its status > http://sourceware.org/ml/gdb-patches/2011-11/msg00337.html > >> The reason is: >> start_tracing: >> for (loc = b->loc; loc; loc = loc->next) >> { >> /* Since tracepoint locations are never duplicated, `inserted' >> flag should be zero. */ >> gdb_assert (!loc->inserted); >> >> target_download_tracepoint (loc); >> >> loc->inserted = 1; >> } >> >> 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. A 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 state changes. If the assert triggers without the tstatus patch, then we should understand how and why. (We might be missing a reconnection case or some such?) Also, I notice that while the testsuite has lots of tstart/tstop sequences, it normally starts a fresh GDB each time, so it was unable to catch this failure. The patch to fix should add a sequence of a couple trace runs in a row to one of the existing test files. Stan