Re: GDB locks RPM database

[Muhammad Umer <umer2834@hotmail.com>]

Thank you for the reply Simon.

But why take a lock? If the purpose is to get info about debug packages, why not just query the package database using rpm command and get the required information? Why is taking a lock necessary?
________________________________
From: Simon Marchi <simark@simark.ca>
Sent: Wednesday, May 20, 2020 5:28:47 AM
To: Muhammad Umer <umer2834@hotmail.com>; gdb@sourceware.org <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 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