From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30838 invoked by alias); 3 Jan 2002 20:15:11 -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 30779 invoked from network); 3 Jan 2002 20:15:05 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 3 Jan 2002 20:15:05 -0000 Received: from redhat.com (reddwarf.cygnus.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA27032; Thu, 3 Jan 2002 12:15:03 -0800 (PST) Message-ID: <3C34BAB2.573376FB@redhat.com> Date: Thu, 03 Jan 2002 12:15:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] Crasher bug in infptrace.c References: <200112310020.fBV0Kr119534@reddwarf.cygnus.com> <3C33F983.4030605@cygnus.com> <3C34AF7B.D6658DC0@redhat.com> <3C34B7FB.7060900@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00013.txt.bz2 Andrew Cagney wrote: > > > > > Will do. > > > > > > > >> > + int alloc = count * sizeof (PTRACE_XFER_TYPE); > >> > + PTRACE_XFER_TYPE *buffer; > >> > + > >> > /* Allocate buffer of that many longwords. */ > >> > ! if (len < GDB_MAX_ALLOCA) > >> > ! { > >> > ! buffer = (PTRACE_XFER_TYPE *) alloca (alloc); > >> > ! } > >> > ! else > >> > ! { > >> > ! buffer = (PTRACE_XFER_TYPE *) xmalloc (alloc); > >> > ! make_cleanup (xfree, buffer); > >> > ! } > > > >> > >> I think it would be better to just abandon the alloca() case and just > >> use xmalloc(). That way the same code path (xmalloc()) is always used > >> and mysterious / obscure bugs that end up being attributed to > >> len?=GDB_MAX_ALLOCA can be avoided. > > > > > > I don't think so -- this function gets called a lot. Heavy use of > > xmalloc on small buffers might lead to fragmentation. Let's try the > > idea of using alloca for small buffers and xmalloc for big ones. > > I think trying to tune an alloca() buffer size is really dangerous. > GDB's crashability starts to depend on how many alloca's have gone > before / after the above call. Regarding fragmentation, wouldn't it be > better to get the code working correctly and only when fragmentation is > demonstrated to be a problem, modify the algorithm. > > Anyway, looking at the code, I'm wondering if it would actually be > better to just eliminate that bounce buffer and, instead just transfer > the data directly. This might leave the buffer in an undefined state, I > think, however, that is ok. I spent an hour thinking about how to do that (without significantly uglifying the code), and decided it was more trouble than I wanted to go to. I agree with you -- the function doesn't require a buffer at all. Anyone who wants to rewrite the function to that extent is more than welcome to by me. ;-)