On 02/11/2011 05:35 PM, Panu Matilainen wrote:
On 02/11/2011 04:57 PM, James Antill wrote:
On Fri, 2011-02-11 at 16:46 +0200, Panu Matilainen wrote:
On 02/11/2011 04:25 PM, seth vidal wrote:
On Fri, 2011-02-11 at 14:20 +0200, Panu Matilainen wrote:
Closing the rpmdb which has active iterators turns the iterators
into zombies that whose locks can only be freed when the process
terminates. Rpm is being a reckless mom...
---
yum/rpmsack.py | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/yum/rpmsack.py b/yum/rpmsack.py
index 0982a7c..24bb9ce 100644
--- a/yum/rpmsack.py
+++ b/yum/rpmsack.py
@@ -658,6 +658,7 @@ class RPMDBPackageSack(PackageSackBase):
po._has_hdr = False
del po.hdr
self._cached_conflicts_data = result.values()
+ del mi
if self.auto_close:
self.ts.close()
@@ -1276,6 +1277,7 @@ class RPMDBPackageSack(PackageSackBase):
break
else:
ret.append(po)
+ del mi
if self.auto_close:
self.ts.close()
why do you have to specifically delete the match iterators?
Because with self.auto_close enabled, ts.close() destroys the
transaction + db handle before the iterator falls out of scope. And when
that happens, the iterator becomes a zombie which is hanging to locks
but cannot be freed.
Gah, another reason to hate auto_close ... ACK.
Can you add a comment to the ts.close() calls though, saying something
like "note all 'mi' have to be gone when we call this" or something.
Ok, will do.
Just FYI, I intend to try and see if this kind of ugly rpm peculiarities
could be hidden away in the ts wrapper & friends. But until that
happens, if it happens...
BTW, an alternative to the explicit iterator deletions would be writing
the dbMatch() uses slightly differently to make it fall out of scope
"naturally". So instead of
mi = ts.dbMatch(...)
for h in mi:
dostuff()
del mi
...in most cases you could use:
for h in ts.dbMatch(...):
dostuff()
This latter variant is broken in rpm < 4.4.2.1 however so if you require
yum to work with the rpm that RHEL 5.0 was originally shipped with then
that's not an option.
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum-devel
