From: Paul Koning <pkoning@equallogic.com>
To: michsnyd@cisco.com
Cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com, wendyp@cisco.com
Subject: Re: [RFC] What to do on VM exhaustion
Date: Thu, 05 Jan 2006 14:50:00 -0000 [thread overview]
Message-ID: <17341.12827.191000.952900@gargle.gargle.HOWL> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2006-01-05 14:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-05 1:00 Michael Snyder
2006-01-05 5:13 ` Eli Zaretskii
[not found] ` <43BD965C.1080500@cisco.com>
2006-01-06 8:50 ` Eli Zaretskii
2006-01-05 14:50 ` Paul Koning [this message]
2006-01-05 22:00 ` Michael Snyder
[not found] ` <b1fa29170601051725t2fc37a96r2dc959a45a2aa92f@mail.gmail.com>
2006-01-06 1:35 ` Michael Snyder
[not found] ` <b1fa29170601051800n452bda22sc28082a2776c858@mail.gmail.com>
2006-01-06 3:16 ` Michael Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17341.12827.191000.952900@gargle.gargle.HOWL \
--to=pkoning@equallogic.com \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb@sources.redhat.com \
--cc=michsnyd@cisco.com \
--cc=wendyp@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox