From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253093.outbound.protection.outlook.com [40.92.253.93]) by sourceware.org (Postfix) with ESMTPS id 48CFB3858D35 for ; Wed, 20 May 2020 01:11:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 48CFB3858D35 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EYEV/54YqOZPhDbD92Y7Y5cJdhg+RVu7Ocv3mKR4OIOGKRUWdJLNXA5Uc5dBzrwcy3zdUEalCsnPcamshIYB1jrJQAHWooUr/VWrVT9YbGOGK5eE5da2N5F+TqK6vuocG4I6Ztx9IqjZuVyKXJRP7xydAwZC+FtAtmra+454wPPfRatGUf57IL6lD9Pbvor+5QGICMyn0ar0h2nnwipNwwjJUtnzvSk4FGp2RY5kmdYup3a7CH0aX7qGPZNy8wJq5jw3J6WGoTDpwga3dA1jbkCvahPso4P7OuY+6P70/sFtfsukxSJbTJlq2T2ygv5kf1hHm3KHOwecUhCy90wL9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C/N1VYAx8PXKToBQI+BpQq2OzuUtXD//3RvXWOcLJWA=; b=TlpG21PNWJFU7wUkm6NBClntN5IH3jjAbCHzGAk6VF3QLf5eeZVonQxvtoDWB2d4yW6jYtWJGxCLWfPkHJEXBmgSdn6TCofCGs/73J8DWGlVF8Ui5xf6QihL6dQFOWSvXqPyUxG7ka5nU9OmPkRZyGzrWH5xsdfz8yaW1w5hSEOicg++aQXva+ySyhZtxYc+Jyz1j34T/PZsF/hynbr7LW5f3389Y1f+MQH4Vr1ulm1S/bhwd+BrxBQ2NWZmM7L4gsnawsQyZbF/aoQinD/FFcme1eRC+5wiiCPR7JJaJ7qGSc0+x1gh8vTBakHEQn0sl84gaAgtuEaYFQSXPdVDuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from PU1APC01FT035.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::52) by PU1APC01HT128.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::313) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19; Wed, 20 May 2020 01:11:41 +0000 Received: from SG2PR06MB2951.apcprd06.prod.outlook.com (2a01:111:e400:7ebe::4b) by PU1APC01FT035.mail.protection.outlook.com (2a01:111:e400:7ebe::214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23 via Frontend Transport; Wed, 20 May 2020 01:11:40 +0000 Received: from SG2PR06MB2951.apcprd06.prod.outlook.com ([fe80::3ccc:500e:361d:50fc]) by SG2PR06MB2951.apcprd06.prod.outlook.com ([fe80::3ccc:500e:361d:50fc%3]) with mapi id 15.20.3000.034; Wed, 20 May 2020 01:11:40 +0000 From: Muhammad Umer To: Simon Marchi , "gdb@sourceware.org" Subject: Re: GDB locks RPM database Thread-Topic: GDB locks RPM database Thread-Index: AQHWLjfPt75c19p3pk+eYP6SK6U+cqiwHtCAgAALX64= Date: Wed, 20 May 2020 01:11:40 +0000 Message-ID: References: , <970dd8cd-d548-b19c-accd-07871b1d9ea1@simark.ca> In-Reply-To: <970dd8cd-d548-b19c-accd-07871b1d9ea1@simark.ca> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:743F0D04AEB08B2769E7A8123BA7DC3486F18C2213D18128D73D60D126EA1E80; UpperCasedChecksum:E6FF8CFC8A6C2BD9BF805BABF4416DA0BC58E6C4F1709B1865E5C035535B40CD; SizeAsReceived:6889; Count:44 x-tmn: [bup+4x4lVKtV8Ycm3XGrPnXhgS0EuTc6] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 3fa4039d-577b-4d31-5db3-08d7fc5ac0e0 x-ms-traffictypediagnostic: PU1APC01HT128: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d6tzo4YvbMy0rMtc5iK2Jbpnc8qZ4pIC3pRDv/F5dR917gy4iv3+sL0Y5lW5ftfaUxUg+z9RRjBu2OtImNrucqH1O163OMPfKeEu8icrsO+b6+hoHwEAlasTISaSW40vJh/f2OxRRSNW1/KcSB1H7Ii2c1/MwDyHBAueNsYZ46J+lhYxIdYws8q7FJn58DEchDLHpZIJPqOvbQx/7P5nPA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:SG2PR06MB2951.apcprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: f7dya2vjXp1MD0rCZfbzLggEAcbx6vuqVaFdWB+bQYJMooH3boTZj6+AnSiInkAtDe4H5/NUfrMs82Ae0dVC1G2CAUy+CBiArJQfgUA0mWpPHFmug6FEb1cqeYzlqa4FQ+Qkx8dWmLfrPHbZE/nYcA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 3fa4039d-577b-4d31-5db3-08d7fc5ac0e0 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 01:11:40.9110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT128 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 01:11:46 -0000 Thank you for the reply Simon. But why take a lock? If the purpose is to get info about debug packages, wh= y not just query the package database using rpm command and get the require= d information? Why is taking a lock necessary? ________________________________ From: Simon Marchi Sent: Wednesday, May 20, 2020 5:28:47 AM To: Muhammad Umer ; gdb@sourceware.org Subject: Re: GDB locks RPM database Changing the list to gdb@. On 2020-05-19 7:47 p.m., Muhammad Umer via Gdb-prs wrote: > > I hope you guys are safe and healthy. > Not sure if this is the right way, but I had a query about GDB, if this i= sn't the right forum, please point me in the right direction. > On my RHEL 7.7 machine, I was using a script that would attach GDB to a r= unning process and collect it's stack trace. After a while, I needed to ins= tall a package on the system. I tried installing a package, but the yum com= mand didn't work, it would just get stuck. I tried installing a package thr= ough rpm command and it would get stuck as well. I could see some locks on = the RPM database, in /var/lib/rpm. I found out using "lslocks" that my GDB = processes had locked the RPM database. I'm not sure why GDB would do that? = Is it by default and is the desired behavior? If it is, under what conditio= ns would GDB acquire a lock on the rpm database? > Thank you. > I've never heard of this. Can this be a RHEL-specific patch? I'm guessing that GDB on RHEL might have a feature to locate debug info pac= kages by querying the package manager, and that's where it would take a lock. Simon