From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253107.outbound.protection.outlook.com [40.92.253.107]) by sourceware.org (Postfix) with ESMTPS id D5356383E80C for ; Wed, 20 May 2020 14:11:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D5356383E80C ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gv3SMQQZFIpJIZTVE3Yhs3TYqsY6mFbXLzYZWIk9cNHiC0kkaZlxtL0GBlSeN//Afltfh2+DLviivLNfhUzv5fLjXSR6TLrHj34hhZ+gr/2zqHJBZX/gzXRwSsTQkhDNlnCG7U1lGSSG/CNZiBXAAtcvLSlDzKQhz7gueNIiGOqBZJcEPkZZNFaBVhlQOiO1IPQaiNjOi/Bvx1x1hPYwEQNt/PtKLvNpXjtFzEjqSy/mpY+KA3OZk/tFPW3D9UulwS3nvdiig23uwl8mDn4TeJ4sNRtDqFIbgM+3VUFN/h5zC/tzKzf7lb+xcvF5dA+IzLpHhszP6JoaWhdHJNSh8Q== 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=OHIIH0fygH7uxcXGIh4fxpPCD8PKoL7dpbGoqOxka/M=; b=X7HVKltFD+aNWzRk1vWMQtnyA3t82q/UaMrQyjD5OVMpcYk/ftrQSYvkbG2sNCic2+45zG+ShpIQYB/H8aD9BHHKdtMqd7fownJDjEsjE2Psg4q/uGBP50txOGz6O08bz2b5pN9WMjXpXUZBFvrIvopalDV+kV2MyOf0zxH8T/8bbMYVt1jJRqu3ntwZ1xPTvP7c3e4e3oESz3DvHtd7ZcQz6EGMQecwXuE0NvAxsezNMBB6A5zLlLapc5Gcvuso55JS2JJAsAYDRdMwDwnuDr5CcFzghO0U8Fyi5kSQTKzRpflAzuYyUn5jEkz5XU8yeDDcjNehFu/Q6kpRb9fHpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from SG2APC01FT037.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::51) by SG2APC01HT185.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebd::490) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Wed, 20 May 2020 14:11:43 +0000 Received: from SG2PR06MB2951.apcprd06.prod.outlook.com (2a01:111:e400:7ebd::4a) by SG2APC01FT037.mail.protection.outlook.com (2a01:111:e400:7ebd::367) 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 14:11:43 +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 14:11:43 +0000 From: Muhammad Umer To: Jan Kratochvil CC: Simon Marchi , Sterling Augustine , "gdb@sourceware.org" Subject: Re: GDB locks RPM database Thread-Topic: GDB locks RPM database Thread-Index: AQHWLjfPt75c19p3pk+eYP6SK6U+cqiwHtCAgAALX66AAAEZAIAAGqIAgAAl9S+AAEyvgIAASw9q Date: Wed, 20 May 2020 14:11:43 +0000 Message-ID: References: <970dd8cd-d548-b19c-accd-07871b1d9ea1@simark.ca> <662b173d-e40b-0f08-fecd-c9df4b3bb51d@simark.ca> , <20200520093903.GA1549168@host1.jankratochvil.net> In-Reply-To: <20200520093903.GA1549168@host1.jankratochvil.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A9B1FBC5621D232FBC9CA47FD725BFD598B4B9A6879045BAF8C758342169A0E3; UpperCasedChecksum:62CCC2DF2EE95103A2920678B09BAF468075E40854F39DB9B66F6D3A60D3CF9B; SizeAsReceived:7366; Count:45 x-tmn: [S1fxUv9JgA/fctly4faXqNWsWgLc/50S] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: cce72b54-5646-4199-7451-08d7fcc7b929 x-ms-traffictypediagnostic: SG2APC01HT185: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J5xA1NKz6aicv9X02H5Xh5z36uhsE3p3j4aBmAIkXY8RzmOGFg/fVYpoiqcYFogP55PyF4G4NaS7C49ykp+CDk1xQqiGgEqshSy9iNDzoxIAdtlAZ+G7hry4ExaHupgJ1amEvTY/Tb7I4uzvPmtO5N5rGcybjgQFf0E+kpZSZQebvIlSg8X6ab5jMs422l6dBG9wMaOlBBY+FWOeTEAVGeS6Xnd6hXGqvaNDeZ97sfnHUISCHL3LEwXSEwXEH1p/ 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: VvXiOKpKAlshVwWCnYVupPvBMqi3Q1R69KyFzN2tkpOQjYgHwvP6YEyB0t3RxzKhUp7VDZyGeENFwlCGIi+T5iBHOs/WMA3SlVnpWbiuecedtxCK3j1V8iW/5P6Sa6uaAI4+NityDNiO9cK/0fMREw== 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: cce72b54-5646-4199-7451-08d7fcc7b929 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 14:11:43.0458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT185 X-Spam-Status: No, score=-2.0 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 14:11:49 -0000 Thanks Jan. Rebuilding rpmdb or removing locks would definitely fix the issue, but I ju= st wanted to find out if there's any specific reason for locking. >From your statement, I'm assuming the gdb version in RHEL 7.7, is using deb= uginfod, and not librpm, right? ________________________________ From: Jan Kratochvil Sent: Wednesday, May 20, 2020, 2:39 PM To: Muhammad Umer Cc: Simon Marchi; Sterling Augustine; gdb@sourceware.org Subject: Re: GDB locks RPM database On Wed, 20 May 2020 07:04:36 +0200, Muhammad Umer via Gdb wrote: > Hopefully RedHat/Fedora folks can offer more insight. I wrote the patch in 2008 using librpm: https://src.fedoraproject.org/rpms/gdb/c/6a80c39af8f12a670c2dc19467= 4a246fe1ded687 I am not aware of such stale locks but then sometimes rpmdb stale locks cou= ld happen even without any GDB involved and 'rpm --rebuilddb' helps in such ca= se (or just 'rm -f /var/lib/rpm/_*' but I am not sure how safe it is). Hopefully it is no longer happening in new RHELs, I do not see it new Fedor= as. Anyway this is really unrelated to upstream GDB and such issues should be filed through your RHEL support contact. Still the librpm support is deprecated and no longer being developed as it = is being replaced by debuginfod support which already landed to upstream GDB. Regards, Jan Kratochvil