From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12175 invoked by alias); 16 Oct 2003 22:14:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12168 invoked from network); 16 Oct 2003 22:14:34 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Oct 2003 22:14:34 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AAGO9-0000BI-MC for ; Thu, 16 Oct 2003 18:14:33 -0400 Date: Thu, 16 Oct 2003 22:14:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA/RFC: vCont for the remote protocol [client] Message-ID: <20031016221433.GA553@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030929152831.GA23286@nevyn.them.org> <20030930211717.GB19869@nevyn.them.org> <3F8C917C.1080708@gnu.org> <20031016203156.GA24204@nevyn.them.org> <3F8F0B2B.9080506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8F0B2B.9080506@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00569.txt.bz2 On Thu, Oct 16, 2003 at 05:18:35PM -0400, Andrew Cagney wrote: > > >Is GDB trying to move away from alloca? The internals manual says: > > > > GDB can use the non-portable function `alloca' for the allocation of > > small temporary values (such as strings). > > >So I use it to avoid cleanups. OTOH, it occurs to me that > >rs->remote_packet_size is a bit large; OTOOH, remote.c uses this idiom > >all over the place already. > > > >I've used xmalloc instead, since the buf is used for getpkt and thus > >must be remote_packet_size large. > > > >Here's what I am about to check in. > > There are two probems: > > - the buffer can get very very large and that can blow the stack > - it isn't possible to audit this code (with out a deep understanding of > that value) and hence demonstrate that the sprintf won't smash the > stack/heap > > You'll need to also change the sprintf to snprintf (parameterized with > remote_packet_size. I don't see a point in doing that until someone expresses interest in thread locking or some other feature which requires adding to the code. The maximum length of any generated vcont packet is the length of: vCont;C01:12341468;C02 The minimum possible buffer size is about twenty times that. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer