Re: fhpd vs RuntimeExceptions

[Phil Muldoon <pmuldoon at redhat dot com>]

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