This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] What to do on VM exhaustion
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Michael Snyder <michsnyd at cisco dot com>
- Cc: gdb-patches at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Fri, 06 Jan 2006 10:50:51 +0200
- Subject: Re: [RFC] What to do on VM exhaustion
- References: <43BC6F36.3050000@cisco.com> <u64ozjlzl.fsf@gnu.org> <43BD965C.1080500@cisco.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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.