From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10651 invoked by alias); 6 Jan 2006 08:50:59 -0000 Received: (qmail 10638 invoked by uid 22791); 6 Jan 2006 08:50:58 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jan 2006 08:50:57 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-160-206.inter.net.il [84.228.160.206]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id CJT31939 (AUTH halo1); Fri, 6 Jan 2006 10:50:50 +0200 (IST) Date: Fri, 06 Jan 2006 08:50:00 -0000 Message-Id: From: Eli Zaretskii To: Michael Snyder CC: gdb-patches@sources.redhat.com, gdb@sources.redhat.com In-reply-to: <43BD965C.1080500@cisco.com> (message from Michael Snyder on Thu, 05 Jan 2006 13:57:48 -0800) Subject: Re: [RFC] What to do on VM exhaustion Reply-to: Eli Zaretskii References: <43BC6F36.3050000@cisco.com> <43BD965C.1080500@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/msg00032.txt.bz2 > Date: Thu, 05 Jan 2006 13:57:48 -0800 > From: Michael Snyder > > > 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. > > It would take more than that. For instance, the failure I'm seeing > is on trying to load a huge symbol file. For graceful recovery, > we would need to register a "cleanup" that would unload the newly > (partially) created symtab. I assumed that we always do this. If not, we should indeed add such a cleanup, particularly before loading symtabs, since those are known as memory hogs. > > If that doesn't > > help, then yes, abort with internal error, since that means GDB leaks > > some significant memory. > > That's what it currently does -- but it stumbles because internal_error > calls query, which does console I/O, which needs to allocate memory, > which fails, which causes it to recurse back into nomem. Then we should do what someone else suggested: reserve a small buffer in advance and free it when we detect the memory exhausted situation, before internal_error is called. But I think we should also add graceful recovery from such situations, where possible. > Instead, we could (for instance) call write (, "VM > exhausted\n") and then abort or exit. That might defeat front ends, so I think we should do this only as the last resort.