From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13201 invoked by alias); 18 Mar 2010 17:59:19 -0000 Received: (qmail 13187 invoked by uid 22791); 18 Mar 2010 17:59:18 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Mar 2010 17:59:11 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2IHx3KX008855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Mar 2010 13:59:04 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2IHx3fd027973; Thu, 18 Mar 2010 13:59:03 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o2IHx2EU013300; Thu, 18 Mar 2010 13:59:03 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 669E5379848; Thu, 18 Mar 2010 11:59:02 -0600 (MDT) From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: RFC: finish_command_continuation and errors References: <201003181728.30450.pedro@codesourcery.com> Reply-To: tromey@redhat.com Date: Thu, 18 Mar 2010 17:59:00 -0000 In-Reply-To: <201003181728.30450.pedro@codesourcery.com> (Pedro Alves's message of "Thu, 18 Mar 2010 17:28:30 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00674.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: >> This can happen if gdb calls error while printing the return value. Pedro> For the record, can you show us which error was that? In this case it was: Value returned is $9 = warning: RTTI symbol not found for class 'java::lang::String' Cannot access memory at address 0x0 Pedro> This probably also fixes frontends: the normal_stop observers Pedro> notification call just a bit below was skipped too, which means Pedro> the MI *stopped notification must have gone missing; a frontend Pedro> was being left with no idea the thread had stopped. Could you Pedro> check with your test, but running with -i=mi, that Pedro> mi_on_normal_stop also isn't throwing an exception too in your Pedro> case? I suspect not, but just in case. You can issue the normal Pedro> CLI commands while in -i=mi to test this. I tried this and it worked fine after my patch. From what I can see, mi_on_normal_stop doesn't try to print the return value. It seems to me that, abstractly, observers should not be allowed to throw exceptions. Perhaps the observer machinery itself ought to catch them. My reasoning is that letting an observer throw an exception will make the observer mechanism apparently unreliable: a given observer might or might not be called, depending on whether some earlier observer encountered an error. Tom