From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34687 invoked by alias); 7 Mar 2019 17:42:51 -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 34679 invoked by uid 89); 7 Mar 2019 17:42:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,KHOP_DYNAMIC,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 spammy=hangup, UD:multi-term-settings.exp, HX-Languages-Length:2761 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; Thu, 07 Mar 2019 17:42:49 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x27HedS5086854 for ; Thu, 7 Mar 2019 12:42:48 -0500 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0a-001b2d01.pphosted.com with ESMTP id 2r36m74p08-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 07 Mar 2019 12:42:47 -0500 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Mar 2019 17:42:47 -0000 Received: from b03cxnp07028.gho.boulder.ibm.com (9.17.130.15) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 7 Mar 2019 17:42:46 -0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x27HgiAu17039378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 7 Mar 2019 17:42:45 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C0B68C6059; Thu, 7 Mar 2019 17:42:44 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 866D2C6057; Thu, 7 Mar 2019 17:42:44 +0000 (GMT) Received: from pedro.localdomain (unknown [9.18.235.79]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 7 Mar 2019 17:42:44 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id CBC343C0D10; Thu, 7 Mar 2019 14:42:41 -0300 (-03) From: Pedro Franco de Carvalho To: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: GDB 8.2.90 available for testing In-Reply-To: <20190227055112.4A5E782D7B@joel.gnat.com> References: <20190227055112.4A5E782D7B@joel.gnat.com> Date: Thu, 07 Mar 2019 17:42:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 19030717-0016-0000-0000-0000098D3D03 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00010721; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01171000; UDB=6.00612049; IPR=6.00951643; MB=3.00025880; MTD=3.00000008; XFM=3.00000015; UTC=2019-03-07 17:42:46 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19030717-0017-0000-0000-000042609B98 Message-Id: <8736ny7f8u.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00160.txt.bz2 Joel Brobecker writes: Hello, There is a regression in the testsuite itself, triggered by errors being raised from within gdb_test_multiple. This looks like a dejagnu issue, but it started happening due to a commit that was introduced for this version, and it can cause the testsuite to hang. The commit that triggers this is: fe1a5cad302b5535030cdf62895e79512713d738 [gdb/testsuite] Log wait status on process no longer exists error The issue is that this commit introduces a new "eof" block in gdb_test_multiple. It doesn't look incorrect to me, but dejagnu uses this block as a "default" action when an error is raised from within the commands inside a call to gdb_test_multiple, which means that it can be executed even when there was no actual eof and the GDB process is still running, so the wait introduced in the commit that tries to get the exit status of GDB hangs forever, while GDB itself waits for input. This only happens when there are internal testsuite errors (not testcase failures). I had noticed it before but the issue that caused the error and triggered this problem was resolved. I saw it again now when I ran the testsuite on a system that restricts ptrace attach operations, which causes an error in "gdb.multi/multi-term-settings.exp", which then hangs the testsuite. This can be reproduced more easily with a testcase such as: gdb_start gdb_test_multiple "show version" "show version" { -re ".*" { error "forced error" } } I'm not sure if there is a proper way to work around this in GDB, but it would be useful so that the testsuite doesn't hang in these cases. Adding an empty "default" block at the end of the expect body in gdb_test_multiple doesn't work, because the dejagnu routine that parses this body and selects the default block to execute after an error is affected by the comments in the body (since they are also parsed). This is proc remote_expect (in dejagnu/lib/remote.exp). In fact, there is already a second eof block that isn't used due to this issue. If this comment in gdb_test_multiple # patterns below apply to any spawn id specified. Is changed to # The patterns below apply to any spawn id specified. Then the second eof block is selected and there is no hang-up. Any comment at that same place with an even-numbered of tokens also works. Of course, this is an ugly solution, and there could be other weird side-effects. Alternatively, the GDB commit that introduced this new eof block could be reverted. This would be unfortunate since it seems useful, but the comment for proc remote_expect does specify that the eof/default/timeout block is used as an error handler, just not which one. Thanks! -- Pedro Franco de Carvalho