From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3523 invoked by alias); 19 Jan 2010 09:22:43 -0000 Received: (qmail 3506 invoked by uid 22791); 19 Jan 2010 09:22:42 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jan 2010 09:22:38 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C8A362BAB7F; Tue, 19 Jan 2010 04:22:36 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id maEM9rE6+IIy; Tue, 19 Jan 2010 04:22:36 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6D4512BAB72; Tue, 19 Jan 2010 04:22:35 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id C3733F5980; Tue, 19 Jan 2010 13:22:27 +0400 (RET) Date: Tue, 19 Jan 2010 09:22:00 -0000 From: Joel Brobecker To: Tristan Gingold Cc: gdb-patches ml Subject: Re: [RFA] windows: do not crash if inferior Message-ID: <20100119092227.GN17397@adacore.com> References: <1C9A707A-AE7C-4947-A9DA-F105674F81AE@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C9A707A-AE7C-4947-A9DA-F105674F81AE@adacore.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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-01/txt/msg00469.txt.bz2 > 2010-01-13 gingold > > * windows-nat.c (do_initial_windows_stuff): Call error() if the > inferior doesn't exist anymore. Just some thoughts, as Chris usually reviews Windows patches... I don't see a "generic" way of dealing with this situation. So the type of approach you took (returning early from do_initial_windows_stuff) seems to be the only approach I can see. I was initially a little reluctant about throwing an error: As far as I can tell from the code, the debugger should have already printed an error message such as "Inferior exited with code ..." (is that correct?) - and so an extra "inferior exited early" message could be considered superfluous. However, if you do not error-out now, core GDB will assume that target_create_inferior succeeded and thus possibly do something unexpected as well. Bottom line - I cannot propose a better approach short of revamping a bit the target_create_inferior routine to add error-handling, I think the patch is fine. I would suggest a different wording, to explain that we were trying to run the program when the error occured. error (_("cannot run program, inferior exited prematurely during startup")); -- Joel