Hi,
I observe occasional hangs in a C++ application that makes RPM
library calls. Attaching to the hung process with gdb, I
obtained the following stack trace (manually created by looking
at the assembly code and stack contents, since the application
was compiled without frame pointers):
__lll_mutex_lock_wait
pthread_mutex_lock
__db_pthread_mutex_lock_rpmdb
__memp_fput_rpmdb
[ unknown static function, probably __db_c_cleanup ]
__db_c_get_rpmdb
__db_c_get_pp_rpmdb
[ unknown static function, probably dbiGet calling db3cget ]
rpmdbNextIterator
[ application code that calls rpmdbNextIterator ]
...
Is this kind of problem familiar to anyone, or does anyone have
any ideas about what may be causing it? The platform is RHEL4
x86_64, and the version of RPM is 4.3.3-26_nonptl (from RedHat).
The application is multithreaded but all RPM library calls are
made by a single thread. The application's use of RPM library
calls is perhaps a bit unusual, and looks essentially like this:
rpmdb db;
int result = rpmdbOpen(NULL, &db, O_RDONLY,
S_IRUSR | S_IRGRP | S_IROTH);
if (result)
{ handle error }
else
{ rpmdbMatchIterator i, j;
i = rpmdbInitIterator(db, RPMDBI_PACKAGES, NULL, 0);
// code goes here that may advance iterator i by calling
// rpmdbNextIterator()
j = rpmdbInitIterator(db, RPMDBI_PACKAGES, NULL, 0);
// code goes here that advances i and j independently
// (according to some complex application-specific logic)
// by calling rpmdbNextIterator(). When application is
// finished using a given iterator, it calls
// rpmdbFreeIterator() on that iterator.
rpmdbClose(db);
}
Is it ok to have multiple rpmdbMatchIterator objects opened at
the same time, advancing them independently within a single
thread? Are there any other potential problems with the code?
Thanks,
Dave
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
