From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-45685-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 32606 invoked by alias); 4 Oct 2006 19:32:20 -0000
Received: (qmail 32598 invoked by uid 22791); 4 Oct 2006 19:32:19 -0000
X-Spam-Check-By: sourceware.org
Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Oct 2006 19:32:17 +0000
Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) 	by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k94JWCVe014914; 	Wed, 4 Oct 2006 21:32:12 +0200 (CEST)
Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) 	by elgar.sibelius.xs4all.nl (8.13.8/8.13.6) with ESMTP id k94JWBEq031070; 	Wed, 4 Oct 2006 21:32:11 +0200 (CEST)
Received: (from kettenis@localhost) 	by elgar.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id k94JWBpG012851; 	Wed, 4 Oct 2006 21:32:11 +0200 (CEST)
Date: Wed, 04 Oct 2006 19:32:00 -0000
Message-Id: <200610041932.k94JWBpG012851@elgar.sibelius.xs4all.nl>
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: brobecker@adacore.com
CC: gdb-patches@sources.redhat.com
In-reply-to: <20061004182505.GH23247@adacore.com> (message from Joel Brobecker 	on Wed, 4 Oct 2006 11:25:05 -0700)
Subject: Re: [RFA/HPUX] somread.c: avoid stack overflow
References:  <20061004182505.GH23247@adacore.com>
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2006-10/txt/msg00016.txt.bz2

> Date: Wed, 4 Oct 2006 11:25:05 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> 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  <brobecker@adacore.com>
> 
>         * somread.c (som_symtab_read): Avoid using alloca for potentially
>         large buffers.
> 
> Tested on pa-hpux, no regression.
> 
> OK to commit?

Looks reasonable to me.