From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18903 invoked by alias); 3 Nov 2016 11:21:18 -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 18887 invoked by uid 89); 3 Nov 2016 11:21:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=dailybuild, Hx-languages-length:1842, daily X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Nov 2016 11:21:16 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8CDD24A54B; Thu, 3 Nov 2016 11:21:15 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA3BLEHR012405; Thu, 3 Nov 2016 07:21:14 -0400 Subject: Re: [RFA 1/2] PR gdb/20604 - fix "quit" when an invalid expression is used To: Ulrich Weigand References: <20161026194417.E142310FDC2@oc8523832656.ibm.com> Cc: Tom Tromey , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <6ffd9182-dfe4-ebaf-8b47-97e30ed21913@redhat.com> Date: Thu, 03 Nov 2016 11:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20161026194417.E142310FDC2@oc8523832656.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00044.txt.bz2 On 10/26/2016 08:44 PM, Ulrich Weigand wrote: > I just noticed that this test case completely breaks my daily testing. > When running the quit.exp test, GDB will hang in a way that it isn't > even killed by the timeout logic, and will keep blocking further > execution forever. > > Attaching to GDB shows it blocked in an ioctl with this backtrace > (which for some reason doesn't even include the quit path ...) > > #0 0x0feea474 in tcsetattr () from /lib/libc.so.6 > #1 0x102d7004 in _set_tty_settings (tty=0, tiop=0x10641adc) at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/rltty.c:476 > #2 0x102d70e0 in set_tty_settings (tty=, tiop=) > at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/rltty.c:490 > #3 0x102d7530 in rl_deprep_terminal () at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/rltty.c:688 > #4 0x102ea2d4 in rl_callback_read_char () at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/callback.c:215 > #5 0x1017defc in gdb_rl_callback_read_char_wrapper (client_data=) > Note that when running GDB directly, quit works fine. The problem > occurs only when running GDB under the DejaGNU framework. In such cases, I suggest inserting a gdb_interact call in the testcase and debugging that way. > Does this ring any bells? Any thoughts what could cause this? The [wait -i $gdb_spawn_id] in the test does look dangerous in the sense that it won't be subject to timeout logic. So if the previous test fails, that'll likely hang forever. Other than that, no ideas. Can you tell from the gdb.log how far the test went? Thanks, Pedro Alves