From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24550 invoked by alias); 20 Feb 2014 14:35:42 -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 24535 invoked by uid 89); 20 Feb 2014 14:35:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f177.google.com Received: from mail-pd0-f177.google.com (HELO mail-pd0-f177.google.com) (209.85.192.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 20 Feb 2014 14:35:41 +0000 Received: by mail-pd0-f177.google.com with SMTP id x10so1877038pdj.36 for ; Thu, 20 Feb 2014 06:35:39 -0800 (PST) X-Received: by 10.66.122.201 with SMTP id lu9mr2512328pab.40.1392906938072; Thu, 20 Feb 2014 06:35:38 -0800 (PST) Received: from [192.168.1.102] ([115.199.121.67]) by mx.google.com with ESMTPSA id yo9sm27058699pab.16.2014.02.20.06.35.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 06:35:37 -0800 (PST) Message-ID: <530612A8.4000903@gmail.com> Date: Thu, 20 Feb 2014 14:35:00 -0000 From: asmwarrior User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org CC: Yao Qi Subject: [Windows]Fix a bug which cause GDB.exe assert when try to run the inferior Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00636.txt.bz2 I see GDB.exe(build from GIT HEAD) can't run any inferior now, it just stops and assert. See the log: [debug]Starting program: E:\code\lex\lessons\001_upn_calculator\bin\Debug\test.exe [debug]../../binutils-gdb/gdb/target.c:1483: internal-error: target_xfer_partial: Assertion `*xfered_len > 0' failed. [debug]A problem internal to GDB has been detected, [debug]further debugging may prove unreliable. [debug]This application has requested the Runtime to terminate it in an unusual way. [debug]Please contact the application's support team for more information. I found that the assert is here: /* Check implementations of to_xfer_partial update *XFERED_LEN properly. Do assertion after printing debug messages, so that we can find more clues on assertion failure from debugging messages. */ if (retval == TARGET_XFER_OK || retval == TARGET_XFER_E_UNAVAILABLE) gdb_assert (*xfered_len > 0); Track down, I found that it is a bug introduced in this commit: SHA-1: 9b409511d07fe375284701af34909fb539029caf 2014-02-11 Yao Qi * Return target_xfer_status in to_xfer_partial This patch does the conversion of to_xfer_partial from LONGEST (*to_xfer_partial) (struct target_ops *ops, enum target_object object, const char *annex, gdb_byte *readbuf, const gdb_byte *writebuf, ULONGEST offset, ULONGEST len); to enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops, enum target_object object, const char *annex, gdb_byte *readbuf, const gdb_byte *writebuf, ULONGEST offset, ULONGEST len, ULONGEST *xfered_len); It changes to_xfer_partial return the transfer status and the transfered length by *XFERED_LEN. Generally, the return status has three stats, - TARGET_XFER_OK, - TARGET_XFER_EOF, - TARGET_XFER_E_XXXX, Especially the change on windows-nat.c @@ -2536,27 +2538,30 @@ windows_xfer_shared_libraries (struct target_ops *ops, } obstack_free (&obstack, NULL); - return len; + *xfered_len = (ULONGEST) len; + return TARGET_XFER_OK; } The original code return len(len could be 0), but the new code just return TARGET_XFER_OK. If len is 0, it should return TARGET_XFER_EOF(it is 0 in enum target_xfer_status declaration. So, a patch below is confirmed to fix the assert issue, an obvious fix, right? gdb/windows-nat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c index a570a1a..b76d94d 100644 --- a/gdb/windows-nat.c +++ b/gdb/windows-nat.c @@ -2480,7 +2480,7 @@ windows_xfer_shared_libraries (struct target_ops *ops, obstack_free (&obstack, NULL); *xfered_len = (ULONGEST) len; - return TARGET_XFER_OK; + return len ? TARGET_XFER_OK : TARGET_XFER_EOF; } static enum target_xfer_status Thanks Yao for the hint, so cc to him. Yuanhui Zhang