From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16560 invoked by alias); 5 Jan 2006 01:00:00 -0000 Received: (qmail 16541 invoked by uid 22791); 5 Jan 2006 00:59:59 -0000 X-Spam-Check-By: sourceware.org Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jan 2006 00:59:58 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 04 Jan 2006 16:58:31 -0800 X-IronPort-AV: i="3.99,331,1131350400"; d="scan'208"; a="690420960:sNHT869877606" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k050wVjt017020; Wed, 4 Jan 2006 16:58:31 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 16:58:31 -0800 Received: from [128.107.165.67] ([128.107.165.67]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 16:58:30 -0800 Message-ID: <43BC6F36.3050000@cisco.com> Date: Thu, 05 Jan 2006 01: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: gdb@sources.redhat.com, gdb-patches@sources.redhat.com, Wendy Peikes Subject: [RFC] What to do on VM exhaustion 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/msg00015.txt.bz2 Hey folks, I don't know how many of you may have ever run into this situation, but my question is, what should we do in gdb when we detect that we are dead out of memory? Theoretically it's handled -- there is a routine in utils.c called "nomem", which calls internal_error. The problem is that internal_error isn't a simple bailout -- it calls query to ask the user what s/he wants to do. And you can't count on something like that working, when you are out of virtual memory. I actually ran into this once before, years ago -- in fact it was RMS himself who called me to beef about gdb bailing on him, when he was debugging emacs and crashed the stack with an infinite recursion. I think gdb ran out of memory while trying to do a backtrace. He wanted me to make it recover gracefully and let him keep debugging. I couldn't do it, but then I didn't have the luxury of having all you guys to ask for advice! In present time, I'm suggesting that nomem should just write a simple error msg to the console and abort. What do you think?