From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15970 invoked by alias); 5 Jan 2006 05:13:39 -0000 Received: (qmail 15954 invoked by uid 22791); 5 Jan 2006 05:13:39 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jan 2006 05:13:38 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-146-4.inter.net.il [80.230.146.4]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DHU05796 (AUTH halo1); Thu, 5 Jan 2006 07:13:21 +0200 (IST) Date: Thu, 05 Jan 2006 05:13:00 -0000 Message-Id: From: Eli Zaretskii To: Michael Snyder CC: gdb@sources.redhat.com, gdb-patches@sources.redhat.com, wendyp@cisco.com In-reply-to: <43BC6F36.3050000@cisco.com> (message from Michael Snyder on Wed, 04 Jan 2006 16:58:30 -0800) Subject: Re: [RFC] What to do on VM exhaustion Reply-to: Eli Zaretskii References: <43BC6F36.3050000@cisco.com> X-IsSubscribed: yes 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/msg00017.txt.bz2 > Date: Wed, 04 Jan 2006 16:58:30 -0800 > From: Michael Snyder > > 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? Perhaps we could do better: we could notice the memory usage each time through the top-level command loop, just before invoking the command dispatch, and then, if we ran out of memory during a command, we could conclude that the last command is the culprit, and throw back to the top level. That would free the memory used up by that last command, and GDB could ``recover gracefully'', as RMS wanted. If that doesn't help, then yes, abort with internal error, since that means GDB leaks some significant memory. The ``doesn't help'' part could be implemented by trying to allocate some memory, just to see if we now have something to continue with, or by comparing the break level to the one we recorded before the command that ran out of memory. WDYT?