--- Begin Message ---
- From: Michael Snyder <michsnyd at cisco dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Date: Thu, 05 Jan 2006 13:57:48 -0800
- Subject: Re: [RFC] What to do on VM exhaustion
- References: <43BC6F36.3050000@cisco.com> <u64ozjlzl.fsf@gnu.org>
Eli Zaretskii wrote:
Date: Wed, 04 Jan 2006 16:58:30 -0800
From: Michael Snyder <michsnyd@cisco.com>
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.
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.
> 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.
Now, somewhere along the line, somebody has wisely coded a recursion
detector, which stops us from falling into infinite recursion.
However, this means that when GDB aborts, the error message is
"infinite recursion detected", rather than "Virtual memory exhausted".
Not as helpful as you would like...
> 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?
Here's the thing -- if the function 'nomem' is called, we know it is
because of exhausted VM. What I'm proposing is that, at this point,
we do NOT want to call internal_error, because that would just fail.
Instead, we could (for instance) call write (<fd of stderr>, "VM
exhausted\n") and then abort or exit. That's what eventually
happens anyway (when the recursive call to internal_error is
detected), but by that time we have lost the original cause and
instead print out a different message about recursion.
--- End Message ---