From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99344 invoked by alias); 11 Oct 2017 13:02:03 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 99323 invoked by uid 89); 11 Oct 2017 13:02:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=shed, Hx-spam-relays-external:sk:EUR03-V, H*RU:sk:EUR03-V, HX-HELO:sk:EUR03-V X-HELO: EUR03-VE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr50085.outbound.protection.outlook.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (40.107.5.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Oct 2017 13:02:00 +0000 Received: from AM3PR08MB0625.eurprd08.prod.outlook.com (10.163.188.151) by AM3PR08MB0628.eurprd08.prod.outlook.com (10.163.188.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 11 Oct 2017 13:01:57 +0000 Received: from AM3PR08MB0625.eurprd08.prod.outlook.com ([fe80::4cde:e2a8:f358:6844]) by AM3PR08MB0625.eurprd08.prod.outlook.com ([fe80::4cde:e2a8:f358:6844%14]) with mapi id 15.20.0077.019; Wed, 11 Oct 2017 13:01:57 +0000 From: Stephen Roberts To: "gdb@sourceware.org" CC: nd Subject: GDB hangs when calling inferior functions Date: Wed, 11 Oct 2017 13:02:00 -0000 Message-ID: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AM3PR08MB0628;6:cVAS0IYpJkACUam7mNnLAUn+pWtgxqQuPife2+R7jfhQjkf10kRsJChsDnxTQkR8In76UdlPI9gx1sialNLSNZWYhVEOSIxfcIluU+awZHla3/HtCFXB9WoePLcMN2a7NbvK9kme6wRT+PrIjcZZF5XQvh257sOwpiN4ICnguD+RHAHr1zq0NVyfMYe7OL+JgLDQQs6OyoWYh99618dEmIOZeTtvdcYAvTd4pLxOmIz2bP1Zc6sOy6UgCu2C0Qj7fEdc5V2idJQS/cnzcqZ2LpgT1UBrQlcXItIl+dJ5zbgFRIaAvJCca5Y3d4AVM2Ja+BYeHzI3DIl2HOQ0ticZlA==;5:/X59K+jNaZlPOsSTqSiV09CRRGE9h9M/wDdFIbAJR1JYBxCYt4ZFhJk7A9JfnBaUUVJuxUrYJ0thcrUCXZunHfU2lY1huAvMr4h6sMNKmdU0eHfjhm/qNHhBrNYbJKzhPJ+6vAxS8WfoPjhQPINK8UA/z5gFs0haBdnpFDiqyhM=;24:WYMf82p0a40X0iJEmq6VSPvCmdf6/a6Z/58/hH0KzTrQXP18zfLlsy/1NVL+tPh4XEdJbwh1U6MUPK7ZAK3nfd4dienYouXbhz7BKbtk2DE=;7:DDvGVV/9obppBjEMHHKHM8FjBXQdgVv+nlzAlYzy7kEv1E8RyMHRJ2lIs+p/pC1WMitvGk/9ATboNTDznzOLiDt+xBMfbkMbYPczaQbtFL0Id64v4yHrWSjmcb5x6KQHJsXzxfDDI2kEFHrX4QkGgSTTNpZsTpxMzQLaii8EnBvWC5ojX2fUhHa+NSxc+TH/ybG8mnTjkeNJY8FJYRFMGHJ08WfTmJT4A2NsDdP5q7k= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0650116d-e923-41e6-9d1f-08d510a840d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:AM3PR08MB0628; x-ms-traffictypediagnostic: AM3PR08MB0628: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Stephen.Roberts@arm.com; nodisclaimer: True x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:AM3PR08MB0628;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:AM3PR08MB0628; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(346002)(39860400002)(376002)(199003)(189002)(5640700003)(66066001)(101416001)(6916009)(55016002)(6506006)(14454004)(33656002)(68736007)(74316002)(99286003)(2900100001)(81156014)(86362001)(305945005)(81166006)(7736002)(102836003)(189998001)(1730700003)(6436002)(8936002)(106356001)(8676002)(6116002)(2501003)(50986999)(54356999)(72206003)(3846002)(4326008)(478600001)(9686003)(97736004)(2351001)(5660300001)(53936002)(7696004)(105586002)(3280700002)(3660700001)(5250100002)(2906002)(316002)(25786009);DIR:OUT;SFP:1101;SCL:1;SRVR:AM3PR08MB0628;H:AM3PR08MB0625.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2017 13:01:56.9769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR08MB0628 X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00032.txt.bz2 Hi folks, I'm encountering a hang in GDB which I have traced back to the infrun_asyn= c(int) function in infrun.c, and wondered if anyone could shed some light = on this part of the code before I raise a bug report. This function is a wr= apper around the mark_async_event_handler and clear_async_event_handler fu= nctions, which set the "ready" member of an async_signal_handler to 1 or 0= , respectively. From what I can tell, this wrapper saves its argument in=A0= a file-scoped variable called infrun_is_async to ensure that it only calls= the mark/clear functions once if it is called repeatedly with the same a= rgument. The hang occurs when GDB tries=A0to call inferior functions on two differen= t threads with scheduler-locking=A0turned on. The first call works fine, wi= th the call to infrun_async(1) causing the signal_handler to be marked and= the event to be handled, but then the event loop resets the "ready" membe= r to zero, while leaving infrun_is_async set to 1. As a result, GDB hangs = if the user switches to another thread and calls a second function because= calling infrun_async(1) a second time has no effect, meaning the inferior= call events are never handled. I've been able to hack around this hang by resetting the infrun_is_async v= ariable to zero, but I'm hoping to find a more elegant solution. With that = in mind, does anyone know what this logic is for? Most of infrun.c just ca= lls the mark/clear functions directly without going through this interface= . Which calls need to use this behavior, and why? This issue affects all versions after 7.12 (including HEAD). For reference,= this is my reproducer for this issue, where get_value is a global function: break after_thread_creation run set scheduler-locking on thread 1 call get_value() thread 2 call get_value() # GDB hangs here Thanks and Regards, Stephen Roberts. >From gdb-return-46105-listarch-gdb=sources.redhat.com@sourceware.org Wed Oct 11 13:24:51 2017 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 103601 invoked by alias); 11 Oct 2017 13:24:50 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 103583 invoked by uid 89); 11 Oct 2017 13:24:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=pulled, Ie, promise 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; Wed, 11 Oct 2017 13:24:48 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 777BE7C846; Wed, 11 Oct 2017 13:24:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 777BE7C846 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id BED0B68D20; Wed, 11 Oct 2017 13:24:44 +0000 (UTC) Subject: Re: GDB hangs when calling inferior functions To: Stephen Roberts , "gdb@sourceware.org" References: Cc: nd From: Pedro Alves Message-ID: <3b857cc7-e722-f10f-7fea-c3928cc0ac36@redhat.com> Date: Wed, 11 Oct 2017 13:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00033.txt.bz2 Content-length: 2446 On 10/11/2017 02:01 PM, Stephen Roberts wrote: > Hi folks, > > I'm encountering a hang in GDB which I have traced back to the > infrun_async(int) function in infrun.c, and wondered if anyone could > shed some light on this part of the code before I raise a bug report. This event source exists to wake up the event loop when we have pending events to handle recorded in the thread data structures. I.e., events that we've already pulled out of the backend (e.g., linux-nat.c), and thus wouldn't otherwise wake up the event loop. > This function is a wrapper around the mark_async_event_handler and > clear_async_event_handler functions, which set the "ready" member of > an async_signal_handler to 1 or 0, respectively. From what I can > tell, this wrapper saves its argument in a file-scoped variable > called infrun_is_async to ensure that it only calls the mark/clear > functions once if it is called repeatedly with the same argument. That's correct. > > The hang occurs when GDB tries to call inferior functions on two > different threads with scheduler-locking turned on. The first call > works fine, with the call to infrun_async(1) causing the > signal_handler to be marked and the event to be handled, but then the > event loop resets the "ready" member to zero, while leaving > infrun_is_async set to 1. As a result, GDB hangs if the user switches > to another thread and calls a second function because calling > infrun_async(1) a second time has no effect, meaning the inferior > call events are never handled. > > I've been able to hack around this hang by resetting the > infrun_is_async variable to zero, but I'm hoping to find a more > elegant solution. With that in mind, does anyone know what this logic > is for? Most of infrun.c just calls the mark/clear functions > directly without going through this interface. Which calls need to > use this behavior, and why? I don't recall off hand, unfortunately. Did you look at git log/blame? > This issue affects all versions after 7.12 (including HEAD). For > reference, this is my reproducer for this issue, where get_value is a > global function: Do you have this in gdb testsuite testcase form? I can't promise to look at this in detail right now, but the easier you make it to try it out, the better. > > break after_thread_creation run set scheduler-locking on thread 1 > call get_value() thread 2 call get_value() # GDB hangs here Thanks, Pedro Alves