From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9300 invoked by alias); 22 Apr 2013 14:32:33 -0000 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 Received: (qmail 9288 invoked by uid 89); 22 Apr 2013 14:32:33 -0000 X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 22 Apr 2013 14:32:32 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1UUHnD-0001Dg-1v from Luis_Gustavo@mentor.com for gdb-patches@sourceware.org; Mon, 22 Apr 2013 07:32:31 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Apr 2013 07:32:30 -0700 Received: from [172.30.7.127] ([172.30.7.127]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Apr 2013 07:32:30 -0700 Message-ID: <517549FC.5070606@codesourcery.com> Date: Mon, 22 Apr 2013 19:03:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "'gdb-patches@sourceware.org'" Subject: [PATCH, remote] Handle 'k' packet errors gracefully Content-Type: multipart/mixed; boundary="------------090101050400030705060009" X-Virus-Found: No X-SW-Source: 2013-04/txt/msg00671.txt.bz2 This is a multi-part message in MIME format. --------------090101050400030705060009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 514 Hi, This is not a real problem with gdbserver, but other types of remote targets (other stubs, QEMU etc) may cut the connection abruptly since they are not required to reply to a 'k' (Kill) packet sent from GDB. The following patch addresses any issues arising from such scenario, which leads to a GDB internal error due to an attempt to pop the target more than once. With the patch, this failure is handled gracefully. As the ChangeLog suggests, i'm sending this on behalf of its original authors. Luis --------------090101050400030705060009 Content-Type: text/x-patch; name="0004-harden_kill.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0004-harden_kill.diff" Content-length: 1832 2013-04-22 Pedro Alves Maciej W. Rozycki gdb/ * remote.c (remote_kill): Handle errors from the kill packet gracefully. Index: gdb/remote.c =================================================================== --- gdb.orig/remote.c 2013-04-22 14:13:25.512124202 +0200 +++ gdb/remote.c 2013-04-22 14:13:39.744123949 +0200 @@ -7714,12 +7714,36 @@ putpkt_for_catch_errors (void *arg) static void remote_kill (struct target_ops *ops) { - /* Use catch_errors so the user can quit from gdb even when we + struct gdb_exception ex; + + /* Catch errors so the user can quit from gdb even when we aren't on speaking terms with the remote system. */ - catch_errors (putpkt_for_catch_errors, "k", "", RETURN_MASK_ERROR); + TRY_CATCH (ex, RETURN_MASK_ERROR) + { + putpkt ("k"); + } + if (ex.reason < 0) + { + if (remote_desc == NULL) + { + /* If we got an (EOF) error that caused the target + to go away, then we're done, that's what we wanted. + "k" is susceptible to cause a premature EOF, given + that the remote server isn't actually required to + reply to "k", and it can happen that it doesn't + even get to reply ACK to the "k". */ + return; + } + + /* Otherwise, something went wrong. We didn't actually kill + the target. Just propagate the exception, and let the + user or higher layers decide what to do. */ + throw_exception (ex); + } - /* Don't wait for it to die. I'm not really sure it matters whether - we do or not. For the existing stubs, kill is a noop. */ + /* We've killed the remote end, we get to mourn it. Since this is + target remote, single-process, mourning the inferior also + unpushes remote_ops. */ target_mourn_inferior (); } --------------090101050400030705060009--