From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18928 invoked by alias); 4 Oct 2006 18:25:15 -0000 Received: (qmail 18884 invoked by uid 22791); 4 Oct 2006 18:25:14 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Oct 2006 18:25:08 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id D5FD548CF27 for ; Wed, 4 Oct 2006 14:25:06 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12026-01 for ; Wed, 4 Oct 2006 14:25:06 -0400 (EDT) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 4994F48CF26 for ; Wed, 4 Oct 2006 14:25:06 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 5389947F00; Wed, 4 Oct 2006 11:25:05 -0700 (PDT) Date: Wed, 04 Oct 2006 18:25:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA/HPUX] somread.c: avoid stack overflow Message-ID: <20061004182505.GH23247@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.4i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00012.txt.bz2 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 572 Hello, A customer of ours ran into a GDB crash that was caused by a stack overflow. Their executables are very large, and it turned out when we started debugging that the overflow happened during an alloca besides which there already was a FIXME:. We replace the calls to alloca by a call to xmalloc followed by make_cleanup and the problem was gone. 2006-10-04 Joel Brobecker * somread.c (som_symtab_read): Avoid using alloca for potentially large buffers. Tested on pa-hpux, no regression. OK to commit? Thanks, -- Joel --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="som.diff" Content-length: 1525 Index: somread.c =================================================================== RCS file: /cvs/src/src/gdb/somread.c,v retrieving revision 1.30 diff -u -p -r1.30 somread.c --- somread.c 1 Mar 2006 05:47:46 -0000 1.30 +++ somread.c 4 Oct 2006 18:20:41 -0000 @@ -88,15 +88,22 @@ som_symtab_read (bfd *abfd, struct objfi number_of_symbols = bfd_get_symcount (abfd); - /* FIXME (alloca): could be quite large. */ - buf = alloca (symsize * number_of_symbols); + /* Allocate a buffer to read in the debug info. + We avoid using alloca because the memory size could be so large + that we could hit the stack size limit. */ + buf = xmalloc (symsize * number_of_symbols); + make_cleanup (xfree, buf); bfd_seek (abfd, obj_som_sym_filepos (abfd), SEEK_SET); val = bfd_bread (buf, symsize * number_of_symbols, abfd); if (val != symsize * number_of_symbols) error (_("Couldn't read symbol dictionary!")); - /* FIXME (alloca): could be quite large. */ - stringtab = alloca (obj_som_stringtab_size (abfd)); + /* Allocate a buffer to read in the som stringtab section of + the debugging info. Again, we avoid using alloca because + the data could be so large that we could potentially hit + the stack size limitat. */ + stringtab = xmalloc (obj_som_stringtab_size (abfd)); + make_cleanup (xfree, stringtab); bfd_seek (abfd, obj_som_str_filepos (abfd), SEEK_SET); val = bfd_bread (stringtab, obj_som_stringtab_size (abfd), abfd); if (val != obj_som_stringtab_size (abfd)) --yrj/dFKFPuw6o+aM--