From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11519 invoked by alias); 5 Jan 2006 22:00:40 -0000 Received: (qmail 11505 invoked by uid 22791); 5 Jan 2006 22:00:39 -0000 X-Spam-Check-By: sourceware.org Received: from sj-iport-4.cisco.com (HELO sj-iport-4.cisco.com) (171.68.10.86) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jan 2006 22:00:37 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2006 14:00:36 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k05M0aWF008385; Thu, 5 Jan 2006 14:00:36 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 14:00:36 -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 14:00:35 -0800 Message-ID: <43BD9703.6080403@cisco.com> Date: Thu, 05 Jan 2006 22:00: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: Paul Koning CC: 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> In-Reply-To: <17341.12827.191000.952900@gargle.gargle.HOWL> 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/msg00026.txt.bz2 Paul Koning wrote: >>>>>>"Michael" == Michael Snyder writes: > > > Michael> Hey folks, I don't know how many of you may have ever run > Michael> into this situation, but my question is, what should we do > Michael> in gdb when we detect that we are dead out of memory? > > Michael> Theoretically it's handled -- there is a routine in utils.c > Michael> called "nomem", which calls internal_error. The problem is > Michael> that internal_error isn't a simple bailout -- it calls query > Michael> to ask the user what s/he wants to do. And you can't count > Michael> on something like that working, when you are out of virtual > Michael> memory. > > That's for sure. And it fails miserably. GDB hangs for a while then > blows up spectacularly. > > Michael> I actually ran into this once before, years ago -- in fact > Michael> it was RMS himself who called me to beef about gdb bailing > Michael> on him, when he was debugging emacs and crashed the stack > Michael> with an infinite recursion. I think gdb ran out of memory > Michael> while trying to do a backtrace. He wanted me to make it > Michael> recover gracefully and let him keep debugging. I couldn't > Michael> do it, but then I didn't have the luxury of having all you > Michael> guys to ask for advice! > > Michael> In present time, I'm suggesting that nomem should just write > Michael> a simple error msg to the console and abort. What do you > Michael> think? > > That would be an improvement over the current broken situation. The > right answer is what RMS said, though. Unfortunately that's likely to > be hard. Yeah, well, until someone's willing to implement garbage collection... ;-/