From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18862 invoked by alias); 29 Mar 2002 07:54:00 -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 18799 invoked from network); 29 Mar 2002 07:53:59 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 29 Mar 2002 07:53:59 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16qrCy-00071m-00 for ; Fri, 29 Mar 2002 02:54:00 -0500 Date: Thu, 28 Mar 2002 23:54:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: Minor off-by-one error in command_line_handler Message-ID: <20020329025400.A25885@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20020327000106.A24311@molenda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020327000106.A24311@molenda.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00600.txt.bz2 On Wed, Mar 27, 2002 at 12:01:07AM -0800, Jason Molenda wrote: > The other problem is with the ALL_BLOCK_SYMBOLS macro. It looks > like this > > /* Macro to loop through all symbols in a block BL. > i counts which symbol we are looking at, and sym points to the current > symbol. */ > #define ALL_BLOCK_SYMBOLS(bl, i, sym) \ > for ((i) = 0, (sym) = BLOCK_SYM ((bl), (i)); \ > (i) < BLOCK_NSYMS ((bl)); \ > ++(i), (sym) = BLOCK_SYM ((bl), (i))) > > Where the block structure (BL) ends with an array of pointers to > symbols. The third expression in the for statement increments the > index variable and reads the address at the i'th element of the > bl->sym[] array. > > So when a block has 2 symbols, bl->sym[0] and bl->sym[1] contain > values. On the last evaluation of this loop, i is pre-incremented > from 1 to 2 and the statement 'sym = bl->nsym[2]' is done - we're > reading one element past the end of the array. > > The invalid memory we just read is not used -- the conditional > expression is then evaluated and the loop exits. The only way > I can see this causing a problem is on a system where reading > that unallocated word of memory would cause a segfault. Unless > other people have heard complaints about gdb 5.1 doing so, I > don't think this is worth worrying about. My fault (and after 5.1, I think). This will cause errors with any good memory checker, so I suppose it should be fixed. This incurs a little slowdown, but was the best way I could think of to do it... OK to check in? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer 2002-03-29 Daniel Jacobowitz * symtab.h (ALL_BLOCK_SYMBOLS): Don't dereference the pointer after the last symbol in a block. Index: symtab.h =================================================================== RCS file: /cvs/src/src/gdb/symtab.h,v retrieving revision 1.29 diff -u -p -r1.29 symtab.h --- symtab.h 2002/03/27 23:10:24 1.29 +++ symtab.h 2002/03/29 07:52:56 @@ -411,7 +411,9 @@ struct block #define ALL_BLOCK_SYMBOLS(bl, i, sym) \ for ((i) = 0, (sym) = BLOCK_SYM ((bl), (i)); \ (i) < BLOCK_NSYMS ((bl)); \ - ++(i), (sym) = BLOCK_SYM ((bl), (i))) + ++(i), (sym) = ((i) < BLOCK_NSYMS ((bl))) \ + ? BLOCK_SYM ((bl), (i)) \ + : NULL) /* Nonzero if symbols of block BL should be sorted alphabetically. Don't sort a block which corresponds to a function. If we did the