From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21501 invoked by alias); 6 Jan 2006 03:16:41 -0000 Received: (qmail 21488 invoked by uid 22791); 6 Jan 2006 03:16:41 -0000 X-Spam-Check-By: sourceware.org Received: from sj-iport-5.cisco.com (HELO sj-iport-5.cisco.com) (171.68.10.87) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 03:16:39 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2006 19:16:38 -0800 X-IronPort-AV: i="3.99,336,1131350400"; d="scan'208"; a="247421091:sNHT33002300" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k063Gcc1020253; Thu, 5 Jan 2006 19:16:38 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 19:16:38 -0800 Received: from [128.107.165.67] ([128.107.165.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 19:16:37 -0800 Message-ID: <43BDE115.3020601@cisco.com> Date: Fri, 06 Jan 2006 03:16:00 -0000 From: Michael Snyder User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 MIME-Version: 1.0 To: kmacy@fsmware.com CC: Paul Koning , gdb@sources.redhat.com, gdb-patches@sources.redhat.com, wendyp@cisco.com Subject: Re: [RFC] What to do on VM exhaustion References: <43BC6F36.3050000@cisco.com> <17341.12827.191000.952900@gargle.gargle.HOWL> <43BD9703.6080403@cisco.com> <43BDC956.1030405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00029.txt.bz2 Kip Macy wrote: > > On 1/5/06, *Michael Snyder* > wrote: > > Kip Macy wrote: > > Why not just pre-allocate a small arena at startup for an "emergency" > > malloc? Hardly ideal, but it would allow gdb to fail gracefully. > > Wouldn't that require modifying malloc? > > > Or do you have in mind that, on detecting out-of-VM, we would > free our little reserved chunk, thus making it available for > libc (or whatever)? > > > What I had in mind was that if we detect out-of-VM we set a flag so that > internal_error would allocate memory from the pre-allocated emergency > memory. Internal error doesn't allocate memory. It calls query, which calls something else, which eventually calls malloc. Hence we would have to change the behavior of malloc. > Or, if there were some way of recovering, but it required some > interim memory, you could allocate from the emergency memory in the > recovery path. Well, all allocation is ultimately done by malloc. OK with some exceptions, but in general, that's where we're hitting the problem. This sounds like modifying malloc. On the other hand, the idea of freeing an emergency reserve just before calling query might have some virtue...