From: Phil Muldoon <pmuldoon@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: frysk@sourceware.org
Subject: Re: fhpd vs RuntimeExceptions
Date: Thu, 15 Nov 2007 17:01:00 -0000 [thread overview]
Message-ID: <473C7B74.6090109@redhat.com> (raw)
In-Reply-To: <1195050364.3027.24.camel@dijkstra.wildebeest.org>
Mark Wielaard wrote:
> Hi,
>
> While investigating some bugs I noticed that the fhpd sometimes swallows
> the RuntimeExceptions from the core (and there I thought all was
> fine...). This makes debugging the fhpd itself a little hard. I added a
> possible exception cause to the Message class and while I was at it
> added checks to make sure we don't present the user with an empty or
> null message (which is very uninformative). Currently we always print
> these possible exception causes when they are attached to a Message in
> CLI.flushMessages(). But we could add a fhpd 'frysk_debug mode' so they
> are only printed if an 'expert' is running frysk. For now I assume all
> users are experts and want to see them, but maybe it is annoying.
> Opinions?
>
Pending a the full implementation of this it's a pain to see every
single exception printed. As talked about on IRC over the corefile
message design, exceptions can and are used to carry warnings, messages
and so on. How do you differentiate between a warning and an error in
this case?
Take this example. I manufactured this warning to happen, but all the
message is telling the user is that it cannot read at the peek() address
given. It's not an error, just a cannot do. But the huge ugly backtrace
that follows is not very useful.
(fhpd) core /home/pmuldoon/core.12463 /bin/bash
Internal debugger error: peek() at address 6992f8 cannot be found in
metadata table.
java.lang.RuntimeException: peek() at address 6992f8 cannot be found in
metadata table.
at frysk.proc.dead.CorefileByteBuffer.peek(fhpd)
at inua.eio.ByteBuffer.peek(fhpd)
at inua.eio.ByteBuffer.peekFully(fhpd)
at inua.eio.ByteBuffer.peekLittle(fhpd)
at inua.eio.ByteBuffer.peekLittle(fhpd)
at inua.eio.ByteOrdered$2.peekULong(fhpd)
at inua.eio.ByteBuffer.getULong(fhpd)
at inua.eio.WordSized$3.getUWord(fhpd)
at inua.eio.ByteBuffer.getUWord(fhpd)
at frysk.proc.dead.LinuxProc.sendrecMaps(fhpd)
at frysk.proc.Proc.getMaps(fhpd)
at frysk.dwfl.DwflFactory.updateDwfl(fhpd)
at frysk.dwfl.DwflCache.getDwfl(fhpd)
at frysk.debuginfo.DebugInfoFrame.getScopes(fhpd)
at frysk.debuginfo.DebugInfoStackFactory.createVirtualStackTrace(fhpd)
at frysk.hpd.CoreCommand.interpret(fhpd)
at frysk.hpd.ParameterizedCommand.interpret(fhpd)
at frysk.hpd.MultiLevelCommand.interpret(fhpd)
at frysk.hpd.CLI.execCommand(fhpd)
at frysk.bindir.fhpd.main(fhpd)
If this is the way forward, I'll have to gobble exceptions locally in
CoreCommand, and just deal with them locally. I kind of liked the way
that fhpd would deal with them, and rank severity on Runtime, or NPE, or
whatever. This relieved the subcommands writing their own mandatory
handlers. (right now you can still do that as an option).
Regards
Phil
next prev parent reply other threads:[~2007-11-15 17:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 14:27 Mark Wielaard
2007-11-14 14:45 ` Andrew Cagney
2007-11-14 15:27 ` Kris Van Hees
2007-11-14 15:36 ` Mark Wielaard
2007-11-14 17:33 ` Andrew Cagney
2007-11-14 19:11 ` Mark Wielaard
2007-11-15 17:01 ` Phil Muldoon [this message]
2007-11-15 17:42 ` Mark Wielaard
2007-11-15 18:19 ` Phil Muldoon
2007-11-15 18:25 ` Sami Wagiaalla
2007-11-16 11:21 ` Mark Wielaard
2007-11-15 18:21 ` Sami Wagiaalla
2007-11-15 20:33 ` Kris Van Hees
2007-11-16 10:12 ` Mark Wielaard
2007-11-15 18:46 ` Andrew Cagney
2007-11-16 10:15 ` Mark Wielaard
2007-11-15 20:41 ` Kris Van Hees
2007-11-15 22:11 ` Phil Muldoon
2007-11-15 23:09 ` Kris Van Hees
2007-11-16 10:42 ` Mark Wielaard
2007-11-15 18:04 ` Mark Wielaard
2007-11-15 18:22 ` Phil Muldoon
2007-11-15 19:06 ` Andrew Cagney
2007-11-16 10:28 ` Mark Wielaard
2007-11-16 14:32 ` Andrew Cagney
2007-11-26 10:18 ` Mark Wielaard
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=473C7B74.6090109@redhat.com \
--to=pmuldoon@redhat.com \
--cc=frysk@sourceware.org \
--cc=mark@klomp.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).