Created attachment 502050 [details] reproducer Description of problem: I'm getting strange errors in rpmreaper when the rpm database is read for second time. The package list is empty after pressing ctrl-R or a commit. It seems to be caused by calling rpmcliInit/rpmcliFini twice, but I'm not sure if this is a bug in rpm or the client Version-Release number of selected component (if applicable): rpm-4.9.0-6.fc15.x86_64 How reproducible: always Steps to Reproduce: 1. run the attached reproducer Actual results: error: no dbpath has been set error: cannot open Packages database in error: no dbpath has been set error: cannot open Packages database in Expected results: No error
(In reply to comment #0) > I'm getting strange errors in rpmreaper when the rpm database is read for > second time. The package list is empty after pressing ctrl-R or a commit. > > It seems to be caused by calling rpmcliInit/rpmcliFini twice, but I'm not sure > if this is a bug in rpm or the client Mostly client error: you do not want to call these repeatedly under normal circumstances. You basically want to call rpmcliInit() early in main() and rpmcliFini() just before exit from main(). Rpm >= 4.9.0 frees more resources in rpmcliFini() than older versions did, so where the older versions leaked memory rpm now refuses to work on the second round as rpmcliInit() doesn't do anything on the second call because of a missing reset of "have we initialized yet" flag in rpmcliFini() (this was missing in older versions too but they "worked" because of the leaks). That's fixed upstream now, but rpmreaper should be changed not to do it anyway as I seriously doubt it has a "good" reason for doing it.
Ok, thanks. IIRC the reason why rpmreaper did this is that originally there was no state preserved across rpmdb reads. BTW, valgrind still reports some memory leaks from rpm. Again, this could be a bug in the client. ==21441== 26 bytes in 2 blocks are definitely lost in loss record 33 of 106 ==21441== at 0x4C2840D: malloc (vg_replace_malloc.c:236) ==21441== by 0x744CF64: __os_malloc (in /lib64/libdb-4.8.so) ==21441== by 0x744D053: __os_strdup (in /lib64/libdb-4.8.so) ==21441== by 0x741FBEE: __env_config (in /lib64/libdb-4.8.so) ==21441== by 0x7420BF9: __env_open (in /lib64/libdb-4.8.so) ==21441== by 0x4E42067: ??? (in /usr/lib64/librpm.so.2.0.0) ==21441== by 0x4E49362: ??? (in /usr/lib64/librpm.so.2.0.0) ==21441== by 0x4E49878: ??? (in /usr/lib64/librpm.so.2.0.0) ==21441== by 0x4E6E1E7: rpmtsOpenDB (in /usr/lib64/librpm.so.2.0.0) ==21441== by 0x4E6E485: rpmtsInitIterator (in /usr/lib64/librpm.so.2.0.0) ==21441== by 0x4E6E661: ??? (in /usr/lib64/librpm.so.2.0.0) ==21441== by 0x4E6E4A1: rpmtsInitIterator (in /usr/lib64/librpm.so.2.0.0)
rpmreaper-0.1.6-8.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/rpmreaper-0.1.6-8.fc15
Package rpmreaper-0.1.6-8.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rpmreaper-0.1.6-8.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/rpmreaper-0.1.6-8.fc15 then log in and leave karma (feedback).
rpmreaper-0.1.6-8.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Just FYI, rpm >= 4.9.1 (in rawhide, F15 update to follow) resets the cli-configured status on rpmcliInit()