Re: [RFC] What to do on VM exhaustion

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 05 Jan 2006 13:57:48 -0800
> From: Michael Snyder <michsnyd@cisco.com>
> 
> > 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 (<fd of stderr>, "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.