This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] What to do on VM exhaustion


>>>>> "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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]