From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23808 invoked by alias); 15 Nov 2007 22:11:51 -0000 Received: (qmail 23798 invoked by uid 22791); 15 Nov 2007 22:11: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 22:11:48 +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 lAFMBUxY024256; Thu, 15 Nov 2007 17:11:30 -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 lAFMBTfh010713; Thu, 15 Nov 2007 17:11:29 -0500 Received: from localhost.localdomain (vpn-6-3.fab.redhat.com [10.33.6.3]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lAFMBNEw028485; Thu, 15 Nov 2007 17:11:24 -0500 Message-ID: <473CC40A.6010104@redhat.com> Date: Thu, 15 Nov 2007 22:11:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.6 (X11/20070926) MIME-Version: 1.0 To: Kris Van Hees CC: Mark Wielaard , frysk@sourceware.org Subject: Re: fhpd vs RuntimeExceptions References: <1195050364.3027.24.camel@dijkstra.wildebeest.org> <473C7B74.6090109@redhat.com> <1195148516.3010.27.camel@dijkstra.wildebeest.org> <20071115204038.GC17388@oracle.com> In-Reply-To: <20071115204038.GC17388@oracle.com> 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/msg00145.txt.bz2 Kris Van Hees wrote: > On Thu, Nov 15, 2007 at 06:41:56PM +0100, Mark Wielaard wrote: > >> Hi Phil, >> >>> << Example exception output deleted - see original message for details. >> >>> If this is the way forward, I'll have to gobble exceptions locally in >>> CoreCommand, and just deal with them locally. >>> >> Yes, I think that is the way forward. Something terribly failed. And >> just passing the "address 6992f8 cannot be found in metadata table." >> message to the user is clearly not very helpful if the user just wanted >> to run a specific command. Only the command knows if this is something >> fatal or not and should catch it at the appropriate level and report >> what the exact action was that was attempted and which structure >> couldn't be created because of the error. >> > > I do not think that an exception like this should ever get handled at the > level of the command module. In fact, in a case like this it should never > have floated up that high without getting handled. Clearly, being unable to > peek at the given address was the result of trying to do some action. The > failure to peek at the address either causes that action to fail, or it can be > ignored (or otherwise recovered from). Either way, the command module should > not be exposed to this level of detail (though the information may need to be > retained as a nested exception for more verbose output, etc...). > Well yes and no. Perhaps I agree with the overall assertions but the corefile user should always recognizes that a corefile is created from a dead or dying process (or just a snapshot in some cases). Let's assume the former for now. The big use-case around core-files is that programmers use them to debug a process that died some time ago. That process might have been in any kind of corrupted state. Therefore a read at an address that is expected to be sane, but is not, should absolutely be reported. But is it an error in the core file code itself? No. It duly tried to do as asked, but failed. It cannot diagnose why that failure occurred, just that it did. It can mean corrupt segments, missing linkmaps table, screwed up dynamic segment and a whole host of other issues the user (the programmer) should know about via this feedback. I keep bringing this example up as this is my pain now; and perhaps it is a special case - but normally they are what define the boundaries of the rules. As it is right now, this is an exception as in "Cannot read where you want me to read", but it is not an error condition simply as it is just honestly reporting that it cannot do what one asked. Because a data read at 0x12345 address is invalid, it should not print a stacktrace to that effect. This is not an error in the corefile code, but the corefile itself. That's pretty much the crux of the argument, and separating out messaging from true errors. Anyway, just wanted to give some background to that exception. I realize now I should have gone into more detail here earlier. Regards Phil