* Re: GDB locks RPM database [not found] <SG2PR06MB29510548426E2177D7C7BAAFCDB90@SG2PR06MB2951.apcprd06.prod.outlook.com> @ 2020-05-20 0:28 ` Simon Marchi 2020-05-20 1:11 ` Muhammad Umer 0 siblings, 1 reply; 9+ messages in thread From: Simon Marchi @ 2020-05-20 0:28 UTC (permalink / raw) To: Muhammad Umer, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 0:28 ` GDB locks RPM database Simon Marchi @ 2020-05-20 1:11 ` Muhammad Umer 2020-05-20 1:13 ` Sterling Augustine 0 siblings, 1 reply; 9+ messages in thread From: Muhammad Umer @ 2020-05-20 1:11 UTC (permalink / raw) To: Simon Marchi, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 1:11 ` Muhammad Umer @ 2020-05-20 1:13 ` Sterling Augustine 2020-05-20 2:48 ` Simon Marchi 0 siblings, 1 reply; 9+ messages in thread From: Sterling Augustine @ 2020-05-20 1:13 UTC (permalink / raw) To: Muhammad Umer; +Cc: Simon Marchi, gdb 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 1:13 ` Sterling Augustine @ 2020-05-20 2:48 ` Simon Marchi 2020-05-20 5:04 ` Muhammad Umer 0 siblings, 1 reply; 9+ messages in thread From: Simon Marchi @ 2020-05-20 2:48 UTC (permalink / raw) To: Sterling Augustine, Muhammad Umer; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 2:48 ` Simon Marchi @ 2020-05-20 5:04 ` Muhammad Umer 2020-05-20 9:39 ` Jan Kratochvil 0 siblings, 1 reply; 9+ messages in thread From: Muhammad Umer @ 2020-05-20 5:04 UTC (permalink / raw) To: Simon Marchi, Sterling Augustine; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 5:04 ` Muhammad Umer @ 2020-05-20 9:39 ` Jan Kratochvil 2020-05-20 14:11 ` Muhammad Umer 0 siblings, 1 reply; 9+ messages in thread From: Jan Kratochvil @ 2020-05-20 9:39 UTC (permalink / raw) To: Muhammad Umer; +Cc: Simon Marchi, Sterling Augustine, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 9:39 ` Jan Kratochvil @ 2020-05-20 14:11 ` Muhammad Umer 2020-05-20 14:34 ` Jan Kratochvil 0 siblings, 1 reply; 9+ messages in thread From: Muhammad Umer @ 2020-05-20 14:11 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Simon Marchi, Sterling Augustine, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 14:11 ` Muhammad Umer @ 2020-05-20 14:34 ` Jan Kratochvil 2020-05-21 0:17 ` Muhammad Umer 0 siblings, 1 reply; 9+ messages in thread From: Jan Kratochvil @ 2020-05-20 14:34 UTC (permalink / raw) To: Muhammad Umer; +Cc: Simon Marchi, Sterling Augustine, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB locks RPM database 2020-05-20 14:34 ` Jan Kratochvil @ 2020-05-21 0:17 ` Muhammad Umer 0 siblings, 0 replies; 9+ messages in thread From: Muhammad Umer @ 2020-05-21 0:17 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Simon Marchi, Sterling Augustine, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-05-21 0:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <SG2PR06MB29510548426E2177D7C7BAAFCDB90@SG2PR06MB2951.apcprd06.prod.outlook.com>
2020-05-20 0:28 ` GDB locks RPM database Simon Marchi
2020-05-20 1:11 ` Muhammad Umer
2020-05-20 1:13 ` Sterling Augustine
2020-05-20 2:48 ` Simon Marchi
2020-05-20 5:04 ` Muhammad Umer
2020-05-20 9:39 ` Jan Kratochvil
2020-05-20 14:11 ` Muhammad Umer
2020-05-20 14:34 ` Jan Kratochvil
2020-05-21 0:17 ` Muhammad Umer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).