From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id E28013858D35 for ; Wed, 20 May 2020 00:28:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E28013858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 754401E5F9; Tue, 19 May 2020 20:28:48 -0400 (EDT) Subject: Re: GDB locks RPM database To: Muhammad Umer , "gdb@sourceware.org" References: From: Simon Marchi Message-ID: <970dd8cd-d548-b19c-accd-07871b1d9ea1@simark.ca> Date: Tue, 19 May 2020 20:28:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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 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 00:28:50 -0000 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 isn'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 running process and collect it's stack trace. After a while, I needed to install a package on the system. I tried installing a package, but the yum command didn't work, it would just get stuck. I tried installing a package through 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 conditions 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 packages by querying the package manager, and that's where it would take a lock. Simon