From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20729 invoked by alias); 15 Nov 2007 17:01:51 -0000 Received: (qmail 20717 invoked by uid 22791); 15 Nov 2007 17:01:50 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS,TW_FH X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Nov 2007 17:01:46 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lAFH1hg0002529; Thu, 15 Nov 2007 12:01:43 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAFH1gSq008646; Thu, 15 Nov 2007 12:01:42 -0500 Received: from localhost.localdomain (vpn-6-16.fab.redhat.com [10.33.6.16]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAFH1fGE004135; Thu, 15 Nov 2007 12:01:41 -0500 Message-ID: <473C7B74.6090109@redhat.com> Date: Thu, 15 Nov 2007 17:01:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.6 (X11/20070926) MIME-Version: 1.0 To: Mark Wielaard CC: frysk@sourceware.org Subject: Re: fhpd vs RuntimeExceptions References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> In-Reply-To: <1195050364.3027.24.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00134.txt.bz2 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