From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32566 invoked by alias); 13 Oct 2009 17:25:33 -0000 Received: (qmail 32529 invoked by uid 22791); 13 Oct 2009 17:25:31 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 17:25:25 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 5CBE118023; Tue, 13 Oct 2009 10:25:24 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id 4EDC1DC078; Tue, 13 Oct 2009 10:25:24 -0700 (PDT) Message-ID: <4AD4B6D8.3030003@vmware.com> Date: Tue, 13 Oct 2009 17:25:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jiang Jilin CC: "gdb-patches@sourceware.org" , Hui Zhu Subject: Re: [RFA] Fix off-by-one error in record.c (record_list_release_first) References: <4AD35AB6.2050903@vmware.com> <7d77a27d0910121917w4abfc09cx43e5667393ef9f79@mail.gmail.com> In-Reply-To: <7d77a27d0910121917w4abfc09cx43e5667393ef9f79@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2009-10/txt/msg00276.txt.bz2 Jiang Jilin wrote: > On Tue, Oct 13, 2009 at 12:35 AM, Michael Snyder wrote: >> Hui, >> >> My "info record" patch helped me to find a bug. >> I found that, once we start calling record_list_release_first, >> we start adding two instructions to the log for every one >> instruction we remove. Therefore the log continues to grow, >> even though it is supposed to remain constant in size. >> >> This is because record_insn_num is not incremented if we >> call record_list_release_first -- but record_list_release_first >> does decrement it. > > Hi Michael, > > I've noticed this bug(maybe) earlier, but I prefer fixing the caller > functions, not the callee function record_list_release_first. And > your patch doesn't handle set_record_insn_max_num. I understand your first point (about caller vs. callee), but I don't understand what you mean about "handling" set_record_insn_max_num. In what way does it need handling? There is still a user command to set and show that variable: add_setshow_zinteger_cmd ("insn-number-max", no_class, &record_insn_max_num, _("Set record/replay buffer limit."), _("Show record/replay buffer limit."), _("\ Set the maximum number of instructions to be stored in the\n\ record/replay buffer. Zero means unlimited. Default is 200000."), > > Thanks! > > 2009-10-13 Michael Snyder > Jiang Jilin > > * record.c (record_message): Increase record_insn_num after > record_list_release_first. > (record_registers_change): Ditto. > (record_xfer_partial): Ditto. > > diff --git a/gdb/record.c b/gdb/record.c > index 8b56010..0208dac 100644 > --- a/gdb/record.c > +++ b/gdb/record.c > @@ -438,8 +438,8 @@ record_message (void *args) > > if (record_insn_num == record_insn_max_num && record_insn_max_num) > record_list_release_first (); > - else > - record_insn_num++; > + > + record_insn_num++; > > return 1; > } > @@ -1008,8 +1008,8 @@ record_registers_change (struct regcache > *regcache, int regnum) > > if (record_insn_num == record_insn_max_num && record_insn_max_num) > record_list_release_first (); > - else > - record_insn_num++; > + > + record_insn_num++; > } > > static void > @@ -1121,8 +1121,8 @@ record_xfer_partial (struct target_ops *ops, > enum target_object object, > > if (record_insn_num == record_insn_max_num && record_insn_max_num) > record_list_release_first (); > - else > - record_insn_num++; > + > + record_insn_num++; > } > > return record_beneath_to_xfer_partial (record_beneath_to_xfer_partial_ops,