Re: GDB locks RPM database

Re: GDB locks RPM database

[Simon Marchi]

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

Re: GDB locks RPM database

[Muhammad Umer]

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

Re: GDB locks RPM database

[Sterling Augustine]

On Tue, May 19, 2020 at 6:11 PM Muhammad Umer via Gdb <gdb@sourceware.org>
wrote:

> 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?
>

 Simon didn't implement the functionality, so you would have to ask redhat,
or whomever it was that wrote the code. This is not a part of a normal gdb
installation.

Re: GDB locks RPM database

[Simon Marchi]

On 2020-05-19 9:13 p.m., Sterling Augustine via Gdb wrote:
> On Tue, May 19, 2020 at 6:11 PM Muhammad Umer via Gdb <gdb@sourceware.org>
> wrote:
> 
>> 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?
>>
> 
>  Simon didn't implement the functionality, so you would have to ask redhat,
> or whomever it was that wrote the code. This is not a part of a normal gdb
> installation.

Indeed.  I peeked at the Fedora local patches, and this one seems to implement
that feature, using librpm

  https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-6.6-buildid-locate-rpm.patch

So it's plausible that librpm takes a lock, and that lock wasn't cleaned up
(perhaps because of crash), but I can't know for sure.  Hopefully someone from
Red Hat / Fedora can help more.

Simon

Re: GDB locks RPM database

[Muhammad Umer]

Thank you Simon! This helps a lot.

Hopefully RedHat/Fedora folks can offer more insight.
________________________________
From: Simon Marchi <simark@simark.ca>
Sent: Wednesday, May 20, 2020 7:48:44 AM
To: Sterling Augustine <saugustine@google.com>; Muhammad Umer <umer2834@hotmail.com>
Cc: gdb@sourceware.org <gdb@sourceware.org>
Subject: Re: GDB locks RPM database

On 2020-05-19 9:13 p.m., Sterling Augustine via Gdb wrote:
> On Tue, May 19, 2020 at 6:11 PM Muhammad Umer via Gdb <gdb@sourceware.org>
> wrote:
>
>> 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?
>>
>
>  Simon didn't implement the functionality, so you would have to ask redhat,
> or whomever it was that wrote the code. This is not a part of a normal gdb
> installation.

Indeed.  I peeked at the Fedora local patches, and this one seems to implement
that feature, using librpm

  https://src.fedoraproject.org/rpms/gdb/blob/master/f/gdb-6.6-buildid-locate-rpm.patch

So it's plausible that librpm takes a lock, and that lock wasn't cleaned up
(perhaps because of crash), but I can't know for sure.  Hopefully someone from
Red Hat / Fedora can help more.

Simon

Re: GDB locks RPM database

[Jan Kratochvil]

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/6a80c39af8f12a670c2dc194674a246fe1ded687

I am not aware of such stale locks but then sometimes rpmdb stale locks could
happen even without any GDB involved and 'rpm --rebuilddb' helps in such case
(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 Fedoras.

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

Re: GDB locks RPM database

[Muhammad Umer]

Thanks Jan.

Rebuilding rpmdb or removing locks would definitely fix the issue, but I just 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 debuginfod, and not librpm, right?

________________________________
From: Jan Kratochvil <jan.kratochvil@redhat.com>
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/6a80c39af8f12a670c2dc194674a246fe1ded687

I am not aware of such stale locks but then sometimes rpmdb stale locks could
happen even without any GDB involved and 'rpm --rebuilddb' helps in such case
(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 Fedoras.

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

Re: GDB locks RPM database

[Jan Kratochvil]

On Wed, 20 May 2020 16:11:43 +0200, Muhammad Umer wrote:
> From your statement, I'm assuming the gdb version in RHEL 7.7, is using
> debuginfod, and not librpm, right?

All Fedora+RHEL releases still use librpm. debuginfod could be expected in
RHEL-9+ or some future RHEL-8.y release (but RHEL-8.y maybe not) but nobody
knows what will be released in the future.

BTW you should always use Developer Toolset GDB on any RHEL.
This will provide you more recent GDB release on RHEL.
The base RHEL system GDB is there for some compatibility reasons only.


Regards,
Jan Kratochvil

Re: GDB locks RPM database

[Muhammad Umer]

Thank you all for your valuable inputs. I really appreciate it.

On May 20 2020, at 7:34 pm, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> On Wed, 20 May 2020 16:11:43 +0200, Muhammad Umer wrote: > From your statement, I'm assuming the gdb version in RHEL 7.7, is using > debuginfod, and not librpm, right? All Fedora+RHEL releases still use librpm. debuginfod could be expected in RHEL-9+ or some future RHEL-8.y release (but RHEL-8.y maybe not) but nobody knows what will be released in the future. BTW you should always use Developer Toolset GDB on any RHEL. This will provide you more recent GDB release on RHEL. The base RHEL system GDB is there for some compatibility reasons only. Regards, Jan Kratochvil