This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] What to do on VM exhaustion
- From: Paul Koning <pkoning at equallogic dot com>
- To: michsnyd at cisco dot com
- Cc: gdb at sources dot redhat dot com, gdb-patches at sources dot redhat dot com, wendyp at cisco dot com
- Date: Thu, 5 Jan 2006 09:50:03 -0500
- Subject: Re: [RFC] What to do on VM exhaustion
- References: <43BC6F36.3050000@cisco.com>
>>>>> "Michael" == Michael Snyder <michsnyd@cisco.com> writes:
Michael> Hey folks, I don't know how many of you may have ever run
Michael> into this situation, but my question is, what should we do
Michael> in gdb when we detect that we are dead out of memory?
Michael> Theoretically it's handled -- there is a routine in utils.c
Michael> called "nomem", which calls internal_error. The problem is
Michael> that internal_error isn't a simple bailout -- it calls query
Michael> to ask the user what s/he wants to do. And you can't count
Michael> on something like that working, when you are out of virtual
Michael> memory.
That's for sure. And it fails miserably. GDB hangs for a while then
blows up spectacularly.
Michael> I actually ran into this once before, years ago -- in fact
Michael> it was RMS himself who called me to beef about gdb bailing
Michael> on him, when he was debugging emacs and crashed the stack
Michael> with an infinite recursion. I think gdb ran out of memory
Michael> while trying to do a backtrace. He wanted me to make it
Michael> recover gracefully and let him keep debugging. I couldn't
Michael> do it, but then I didn't have the luxury of having all you
Michael> guys to ask for advice!
Michael> In present time, I'm suggesting that nomem should just write
Michael> a simple error msg to the console and abort. What do you
Michael> think?
That would be an improvement over the current broken situation. The
right answer is what RMS said, though. Unfortunately that's likely to
be hard.
paul