From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101623 invoked by alias); 7 Nov 2016 15:57:28 -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 100835 invoked by uid 89); 7 Nov 2016 15:57:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=ideas, issuing, dailybuild, 2618 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Nov 2016 15:57:26 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uA7FsF5e040692 for ; Mon, 7 Nov 2016 10:57:25 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0b-001b2d01.pphosted.com with ESMTP id 26ju4neyv1-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 07 Nov 2016 10:57:24 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 7 Nov 2016 15:57:23 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 7 Nov 2016 15:57:20 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id ED6371B08072 for ; Mon, 7 Nov 2016 15:59:31 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uA7FvJua13107588 for ; Mon, 7 Nov 2016 15:57:19 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id uA7FvJsF014760 for ; Mon, 7 Nov 2016 08:57:19 -0700 Received: from oc8523832656.ibm.com (dyn-9-152-213-198.boeblingen.de.ibm.com [9.152.213.198]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id uA7FvJkA014751; Mon, 7 Nov 2016 08:57:19 -0700 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id B198310B7A7; Mon, 7 Nov 2016 16:57:18 +0100 (CET) Subject: Re: [RFA 1/2] PR gdb/20604 - fix "quit" when an invalid expression is used To: palves@redhat.com (Pedro Alves) Date: Mon, 07 Nov 2016 15:57:00 -0000 From: "Ulrich Weigand" Cc: tom@tromey.com (Tom Tromey), gdb-patches@sourceware.org In-Reply-To: <6ffd9182-dfe4-ebaf-8b47-97e30ed21913@redhat.com> from "Pedro Alves" at Nov 03, 2016 11:21:13 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16110715-0008-0000-0000-000002EF0062 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16110715-0009-0000-0000-00001AA0D7FF Message-Id: <20161107155718.B198310B7A7@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-07_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611070293 X-SW-Source: 2016-11/txt/msg00139.txt.bz2 Pedro Alves wrote: > 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. Thanks for the tip, this allowed me to debug this further. > > 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? Apparently the problem has nothing to do with the "quit" command in itself; GDB never even gets around to attempt to execute the command. Any test case along the lines of: send_gdb "<...>\n" set result [wait -i $gdb_spawn_id] will result in the same hang on my RHEL 5 system. What happens is that after the send_gdb command has sent the newline to the GDB process, readline triggers its end-of-line machinery. This will call "rl_deprep_terminal", which attempts to reset the TTY to its default settings. This uses the tcsetattr routine with the TCSADRAIN option, which gets translated by glibc into a TCSETSW ioctl. Now this ioctl causes the kernel (at least the 2.6.18 kernel in RHEL 5) to attempt to flush the *write* side of the TTY and wait until that flush has succeeded. However, apparently nobody is *reading* on that side of the TTY (since expect has only performed the send_gdb which writes on the other side of the TTY, and is now in a wait which does not read on any side of the TTY), and thus the wait never returns. Since rl_deprep_terminal also blocks SIGINT while issuing the tcsetattr, this cannot even be interrupted easily. Now I don't fully understand why more recent kernels don't appear to block indefinitely here; maybe something in the TTY buffering changed? In any case, I'm also not sure if the test is really doing the right thing here. Can this not be done using a gdb_expect or any of the other usual constructs that will actually read GDB's TTY output? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com